@sbase Васильев Алексей про свою работу в 2003 над одним из известных счётчиков рунета

Когда перепроектировал движок интернет-статистики возникла проблема (1) быстрого выжирания памяти и (2) "как быстро сохраниться на диск?",

1) потому, что в интернете сплошная тексто-обработка. очень много строчек на входе, их нужно сортировать, считать.появлялась сегментация памяти, и она как бы была, но её не было в блоках нужного размера. 4гигов не хватало.

2) при сохранении на диск, я форкал процесс, и нужно было освободить реально много млн блоков памяти, это занимало времени что тормозило основной процесс.

Решение:
1. перехватываем Allocator для коллекций std::string  и выделяем блоки в своей памяти, добавляя нужные сегменты.
2. когда форкамся, просто сбрасываем указатель на 0 (в начало)

после выхода на рабочий режим , рабочий пул памяти был 700-800М, со сбросом на диск каждые 30 минут. по мере достижения лимита. это обеспечивало скорость 3000 хитов/сек по детальной статистике (1 сервер)

Трюк с памятью взял из gamedev - они делают свое управление памятью по типам данных, они там текстуры хранят и данные игры.

технологии:: C++, STD, linux

@s0t0na рассказывает, как деградировать системы на уровне линукс кернел

Site Reliability Engineering
https://landing.google.com/sre/images/book.png

Масленников Дмитрий пишет, что в Google инженеры хвалятся, кто больше и серьезнее "оутаджи" допустил. Для них важны не понты и перечисление технологии. Ты им покажи свои "постмортемы" и какие выводы ты из них сделал и тогда будет серьёзный разговор :)

Заметьте, что в Гугл много оутаджей в год, но о них почти не слышно. Там наработан огромный опыт и особая культура, как быть с оутаджами. На практике - очень эффективно все работает.

Друзья и коллеги Димы написали даже книгу про это - Site Reliability Engineering.

https://landing.google.com/sre/book.html

Денис Габайдулин прислал истори, как в далёком 2013м у одноклассников легли все сервера из-за двух переносов строк
https://habr.com/company/odnoklassniki/blog/268413/

Однажды вечером система мониторинга зафиксировала незначительную проблему с одним из серверов.

... [тут описание дальнейших танцев] ...

Нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.

Приходилось восстанавливать бэкапы, внося в них накопившиеся логи транзакций, чтобы затем развернуть рабочие копии и запустить сервисы.

Восстановление первичной работоспособности, когда портал стал хотя бы загружаться и заработала часть функционала, заняло около суток.

Авария произошла в четверг вечером, а в воскресенье утром  полностью восстановилась работа портала.

Додо-пицца открывает новый формат вакансий. Что интересно, реально внедрили TDD и парную разработку :)

https://www.youtube.com/watch?v=esva_8RNSuM

Парная разработка и TDD - это то, что есть в вашей команде?
anonymous poll

Дорого и времени нет – 25
👍👍👍👍👍👍👍 49%

Иногда что-то делаем такое во время брейн-штоминга – 14
👍👍👍👍 27%

А вы почему интересуетесь? – 11
👍👍👍 22%

Да, в полный рост – 1
▫️ 2%

👥 51 people voted so far.

@romajke Алексеев Роман пишет про парное программирование:

При работе над некоторыми задачами можно выделить этап прототипирования решения: пишутся простые тесты, выделяются интерфейсы, общая архитектура решения.
Удобно эту часть работы проводить в паре, а затем распараллеливать работу - один реализует, например, доступ к данным, другой - конфигурацию и интерфейс сервиса.

Пары успевают в 1.5-2 раза больше задач. @sbase проверял. Единственная проблема - эмоционально напряжёнее, поэтому нужно делать сессиями,

fb.com/yaroslav.maxymovych Ярослав Максимович пишет про программистов в белых халатах

Сначала известная цитата одного неизвестного программиста: ...я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами.

И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл.

Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков.

Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.

Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты.

Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь.

Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики...

* * *

Вторую часть иллюстрации мне, лет десять назад, рассказывали одни потенциальные покупатели старого интернет-аукциона, когда мы обсуждали технические вопросы, поскольку у нас к тому времени уже было 200 тыс пользователей и десять программистов.

История раннего Ebay:

Первая версия их сайта была смешной, слепленной на коленке. Но внезапно к ним полезли регистрироваться тысячи юзеров ежедневно.

Просто их сайт хорошо и вовремя попал в боль рынка.

И постоянно оч быстро росли.

А сервера стабильно оказывались не готовы к все возростающей нагрузке.

Постоянно добирали программистов, вводили новые функции, неважно по какой причине, то ли по требованию пользователей, или безопасности, или срочности, или чего угодно, не важно в общем. Важно лишь что эти функции были нужны.

В результате, на сервере творилось неизвестно что. Какие-то куски кода, разные версии, зависания, глюки. Программисты в белых халатах негодуют. Но главное что бизнес не останавливался, а продолжал отлично расти и приносить деньги на переписку "с нуля".

К какому-то моменту оказалось что в компании из всех программистов был один главный, который из жадности замкнул на себе все процессы, и только он знал как шаманскими танцами с бубном возвращать работоспособность, когда что-то шло не так.

А это совсем не простая работа в условиях стресса, когда у тебя ежедневно миллионы пользователей с миллионами товаров. То есть, каждая минута простоя стоит реальных денег.

В результате парень вымотался, сказал что ему срочно нужен отпуск. Раздал инструкции и пароли сотрудникам.

И умчался в направлении неизвестного отеля на Багамах, выключив телефон.

Спустя какое-то время сервера опять упали.

Оставшиеся программисты не смогли поднять. Спустя сутки, один из инвесторов психанул, взял самолет и помчался на поиски.

Программиста привезли, сервера подняли.

Это был самый большой, полуторасуточный сбой на Ebay.

Yessssssssss!!!!!!!!!!!!!!!!!!!!!! Мы дожили до того момента, когда можно гордиться своим футболом!

Никогда не думал, что в своей жизни такое напишу, но наша сборная сыграла результативнее Аргентины, Германии, Португалии и, это невероятно, Испании.
Более того, оба гола в игре с Испанией залетели от ноги наших футболистов.
Это невероятно.
Это не-ве-ро-ят-но.

В число неочевидных обязанностей CTO входит жёсткий пуш всей команды для финализации решения на последних метрах дистанции.

Обычная ситуация, когда всё вроде бы по отдельности готово, а вместе не работает. В этом случае требуется аккуратно собрать всё воедино и заставить работать.

Именно тут требуются сила воли и способность концентрировано совершить подвиг.  Это вопрос готовности самого CTO победить, когда карманы есть, рукава есть, полы есть, а пиджака ещё нет.

https://t.me/temno пишет, что обучение – это вам не то

1. Обучение – это вовсе не последовательная передача новых знаний. Обучение – это последовательное устранение существующих непониманий (misconceptions).

2. Тестирование – это вовсе не инструмент для проверки того, чему ученик научился. Ученик может выбрать правильный ответ по десятку не связанных с правильным пониманием причин. Тестирование – это инструмент для выявления непониманий. Каждый неверный вариант должен соответствовать какому-то из базовых непониманий, которое мы хотим отловить и устранить.

3. Применять этот подход можно не только для обучения. Например, продажи – это не процесс убеждения людей в том, что им нужно купить наш продукт, а поиск и устранение причин – в голове потребителя или в нашем продукте – по которым его не покупают.

Подражая Морейнису

Мечта - это вовсе не мысли о чем-то прекрасно. Мечта - это то в направлении чего уже движется ваша жизнь.

@maslennikovdm рассказывает про гугловые практики разработки!

Типы ситуаций для вызова внешних экспертов:

Потушить пожар
В IT отделе давно все плохо. Но лиды рапортовали наверх, что все идет по плану. В определенный момент проблем накопилось столько, что произошел взрыв. Учредитель в панике ищет, кто ему поможет.

Эвакуатор
IT отдел все время “косячит”. Срывают сроки релизов. Не могут пофиксить баги или фиксят, но новых появляется больше. Сервис все время падает, не доступен или слишком медленный. Учредителю объясняют это тем, что “так везде” или какими-то неправдоподобными причинами. Он хочет понять правда ли это, так как сам в этом не разбирается.

Предстартовая подготовка
Новая компания или новый проект или новый большой функционал в старом проекте. Учредитель, или даже CTO или лид сомневаются в выборе технологий и архитектурных решений. Нужен аудит архитектуры прежде чем начать проект.

Регулярный техосмотр
Все вроде бы нормально, но хочется лучше. Нужен аудит процессов, практик, кода и архитектуры, чтобы взглянуть свежим незамыленным взглядом и внести новизну в проект.

Когда вас вызывать?
public poll

Эвакуатор – 12
👍👍👍👍👍👍👍 33%

Потушить пожар – 8
👍👍👍👍👍 22%

У меня нет времени. Не трогайте меня! – 7
👍👍👍👍 19%

Регулярный техосмотр – 5
👍👍👍 14%

Всегда!!! – 3
👍👍 8%

Предстартовая подготовка – 1
👍 3%

👥 36 people voted so far.

Волынкин Николай @Nick_Volynkin  поднимает в своём канале @docops одну из фундаментальных проблем в современной разработки, актуальную для компаний любого размера, начиная от стартапов и заканчивая многослойными большими корпорациями: как замапить код и его изменения на требования бизнеса.

Например, мы хотим поменять какой-то участок кода. Как найти все требования, которые он реализует? Как спрогнозировать последствия от изменения?

Кажется, что для этого нужно заранее выстраивать цепочку от коммитов к задачи в трекере и к общим документам уровня feature vision или контракта. Просто номера задачи в сообщении коммита не хватает — часто в задаче есть описание только на функциональном уровне, но не рассказано про значение для бизнеса.