будни

Когда мы с Федей шли в igooods, то сразу договорились, что нужно развивать технический бренд — он помогает нанимать и удерживать крутых специалистов. Для этого нужно писать статьи и выступать на конференциях; рассказывать, какие крутаны у нас работают и какие интересные технические штуки мы делаем. Благо, историй достаточно.

Стыдно, но пока мы сделали на этом фронте очень мало.

Тем приятнее, что на прошлой неделе мы наконец-то выступили на онлайн-конференции с Андреем Родиным, директором по продукту igooods. Делились тем, как пережили пик заказов при коронавирусе. Андрей рассказал про телеграм-бота, который позволил нам нанять менее квалифицированный персонал для сборки заказов без потери качества. Андрей сам собрал прототип в конструкторе ботов, а наш замечательный бэкендер Сережа прикрутил к нему бэкенд по АПИ за рекордные сроки. Я рассказал, как мы с технической командой роняли и поднимали серверы под нагрузкой.

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

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

Давно не писал, две недели решительно не хотел ничего делать. Хочется свалить всё на пневмонию (не коронавирусную), на самом деле просто устал. Продолбал несколько лидов-клиентов. Раньше бы стыдился, но это тема для отдельного поста.

Между тем, происходит куча всего интересного. В мире пандемия (вот классная визуализация и хорошее видео про неё), а у нас в iGooods рекорд за рекордом. Если раньше в пике было по 70 запросов в секунду, то теперь — больше 400. Каждое выступление Путина — +20% посещаемости.

Чтобы выдерживать такие нагрузки, нужно оптимизировать код и увеличивать объем железа. Серверы масштабируются горизонтально и вертикально. Горизонтально — это когда ставишь рядом со старым сервером ещё один, такой же новый, и они делят нагрузку. Это идеальная схема, так мы сейчас регулярно добавляем серверы приложений. К сожалению, базу данных мы горизонтально масштабировать не умеем — для того, чтобы поставить в параллель два сервера БД, нужна специальная магия, запрогать которую мы не успели.

После последнего выступления Путина мы поняли, что скоро уткнемся в гигабитную сетевую карту на сервере БД (раньше я такого не видел и да, нам нужно переписать эти долбаные запросы). Спасибо огромное селектелу — пошли навстречу и мгновенно собрали кастомный сервер с 10гигабитным интерфейсом. Вот теперь сижу жду, когда ребята потушат на пару минут сайт и переключат базу данных на новую машину. Это — вертикальное масштабирование.

Спокойной ночи! 🌛

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

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

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

Для этого мы пользуемся сервисом datadog. Он дорогой, но стоит своих денег. Главная его сила — не в графиках, а в том, что кроме численных показателей он практически автоматически собирает внутреннее состояние приложения (APM, запросы к базе и вот это всё) и логи (бортовой журнал приложения). Благодаря этому, можно выделить время на графике и увидеть всю отладочную информацию из приложений только за указанный период. Или наоборот, заметить странные логи и одним нажатием посмотреть, как вели себя графики в это время. Это звучит как небольшая и очевидная функция, но во первых, это редкость, а во вторых — очень помогает. Меньше думаешь о том, как найти информацию и больше — о том, что она значит.

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

Мы в iGooods лежали почти полдня. Стыдно! Зря я угорал вчера над утконосом, что они упали. Поделюсь честно, от чего мы лежали. Это подробный постмортем аварии с техническими подробностями, мама, извини.

—

Из-за коронавируса к нам начали приходить в 2-3 раза больше клиентов, чем обычно. Плюс у нас на днях запускается два новых партнерства — с Joom и с магазинами Лента. Серверы работали на 40-60 процентах емкости и мы решили «добавить железа». В 6 вечера мы налили пару новых машин в кластер приложений, в час ночи по Москве — перетащили базу на новую, ультра мощную тачку. Обе операции — необычные для iGooods, множество вещей делалось руками. Ошибка №0 — мы сделали 2 крупных изменения близко друг с другом

В 7 утра по Москве, сервер базы данных начал плавиться от нагрузки в процессор. Это компьютер с 70 ядрами, но базе нужно было минимум 300. Запросов было вроде бы не сильно больше, чем обычно, но занимали они всё больше времени. Люди просыпались у себя дома и начинали делать заказы — сервера умирали, сайт не открывался, приложения выдавали ошибки. Самое опасное — курьеры и сборщики заказов выходили на работу и не могли работать.

Мы, конечно, думали, что сможем быстро починить проблему. Через час стало понятно, что нужно хотя бы временное решение. Мы выключили все пользовательские интерфейсы iGooods, оставив рабочей только админку и внутренние приложения курьеров и пикеров (сборщиков заказов). Ошибка №1 — в случае аварии не нужно пытаться «сделать хорошо», нужно определить критичные сервисы и восстановить их первым делом.

Мы решили, что проблема в новой базе данных. Мало ли, конфигурация, железо, да хоть драйверы. Попытались вернуться на старый сервер. Мы не сохранили WAL логи между переездами, так что вместо 3 минут эта операция заняла 40 минут — пришлось перегнать всю базу данных между серверами. Мы планировали откат для приложений, но не для переноса базы — он нам казался довольно безопасной операцией. Ошибка №2 — мы решили, что «уж тут-то не взорвется», на самом деле вместе с любым изменением нужно продумывать пути отката.

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

В конце концов, Женя случайно заметили ошибку, что наше rails приложение не может записать в redis-кеш. BINGO! Вот тут всё наконец-то встало на свои места. В нашем приложении есть много страниц, которые собираются очень долго. Все они кешируются rails'ами в redis. И вот этот редис кеш у нас отвалился на запись на части серверов приложений из-за кривых настроек окружения (душераздирающие подробности приложены картинкой). Кеш протухал постепенно и с каждой потерянной записью все больше тяжелых запросов грузили Postgres. Ошибки №3, 4 и 5: настройка тачек производится руками, не кодом; логи переполнены, так что сложно заметить новую ошибку; не все важные сервисы (redis, rails cache) включены в мониторинг.

Как вы можете видеть, всё довольно банально. Будь у нас настроена нормальная рабочая среда — не было бы такой аварии.

Итак, чего нам не хватило и что мы приведем в порядок:
- инфраструктура в коде (полный ansible вместо хождения руками на серверы);
- хороший, чистый мониторинг всех ключевых метрик приложения, APM — за день до аварии мы включили Datadog, но ещё не было нормальных дэшбордов и исторических данных;
- сообщения об ошибках (у нас bugsnag) засраны нерелевантными сообщеними — их нужно почистить.

Мы с Федей обозначили проблемы в первые же дни, но не успели решить их — были вещи поважнее. Знал бы прикуп — жил бы в Сочи.

Если у вас похожая ситуация — рекомендую навести порядок заранее, не ждать форс-мажора.

Ну и делать много сложных правок вместе — чревато. Стоило разнести перенос базы и деплой новых машин на день — тогда бы мы не потратили так много времени на ложный след тормозной базы.

Fin.

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

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

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

Интереснее сейчас, наверное, только у эпидемиологов, в медиа и в школах, которые пытаются перейти на удаленку. 🚀

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

Мы с Федей уже почти месяц вместе составляем системный ответ на этот вопрос. Для командной работы мы завели личную базу знаний (что-то вроде своей википедии) в Notion. Мы храним там общие задачи, план и знания, которые собрали в ходе работы. Если заменить информацию о конкретном клиенте подробным описанием, зачем мы делаем тот или иной шаг — может получиться книга «как руководить разработкой в продуктовой компании».

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

Глава I, про бизнес и процессы.

1. Чего бизнес хочет от разработки? Важно не остановиться на конкретной хотелке «напрогайте нам X», а докопаться до бизнес-гипотезы, которую хотят проверить.

2. Как построена работа над продуктом: кто преобразует гипотезу в задачу, как ставится задача разработке, доносится ли гипотеза до программиста, интересуется ли они ею? В здоровой продуктовой команде техническая экспертиза подключается на самом раннем этапе.

3. Что происходит после запуска фичи? Анализируется ли результат? Понимают ли программисты, как они повлияли на бизнес?

4. Как происходит планирование и приемка работы? Смотрим на четкость и ритмичность. Четкость: плохо — «мы тут что-то не особо хорошо описанное напланировали, о том успеем или нет — не задумывались», хорошо — «в понедельник у пользователей в продакшене появится X», нужны конкретные обещания и контроль их выполнения. Ритмичность: продуктовая работа — это почти всегда постепенное улучшение и очень редко — один героический забег. Чтобы система работала годами, ей нужна цикличность, с запланированными фазами «напряжение-расслабление».

Глава II, люди.

5. Команда: в каком состоянии ребята, нравится ли им работа, нравятся ли коллеги, конкурентная ли компенсация? План развития ребят, 360 reviews, 1-1.

6. Уникальность знания. Что будет, если сотрудник уволится или заболеет (bus factor)? Документация, стоимость погружения новых людей в проект.

7. HR: достаточно ли мы рассказываем миру о том, хорошо лиу нас работать? Ведение профессионального блога, выступление на профильных конференциях.

Глава III, технологии.

7. Operations: отказоустойчивость, масштабируемость, мониторинг, incident management, бэкапы, учения. Автоматизация процессов в разработке: среды разработки, деплой, откат, etc..

8. Архитектура и код: модульность, связанность, тесты. Тесты: насколько велика вероятность сломать проект? Радость разработчика: насколько комфортно ребятам работать?

9. Информационная безопасность: DDoS, дырки в коде, операционная безопасность, социальная инженерия. Проводим ли ли пентесты, есть ли баунти-программа, как реагируем на сообщения об уязвимостях?

—

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

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

P.S. У нас есть отличная вакансия для рубиста в Питере.

Я почти не писал сюда в последние месяцы.

Сначала я боялся, что никому не нужен как профессионал. Потом пришел ещё больший ужас, когда понял, что предложения приходят нормальные, а порой даже лестные (бизнесы в десятки миллионов долларов, ААА), просто я не хочу становиться техдиром одной компании на очередные 3-5-10 лет, скучно. Что делать дальше?!

Становиться консультантом, который просто пиздит и не несет ответственности — нет. Прогать за деньги я не люблю. Делать аутсорс-компанию — точно нет: покупаешь программистов по 150 тысяч в месяц и продаешь по 2000 рублей в час, прибыль 50 тысяч рублей в месяц за человека. Больше тел — больше денег.

Особых накоплений у меня нет, а трое детей и жена — есть. Чем заниматься и как зарабатывать на жизнь?!

Я нашел не только ответ, но и партнера, с которым мы начинаем общее дело.

—

Мы с Федей Борщевым предлагаем услуги технического директора плюс. Мы помогаем разобраться в технической стороне вопроса и выстроить крутую внутреннюю разработку. С нами багов, проебанных дедлайнов и падений в продакшене станет меньше, а новые фичи и польза бизнесу будут появляться чаще и ритмичнее. Помощь с наймом программистов (а при необходимости — и техдира), которые будут развивать настроенную нами систему — в комплекте. Главное — всё это будет работать и после нашего ухода.

Можем найти крутых программистов и быстро запустить MVP. Порой мы отвечаем «да не нужно тут ничего прогать, давай лучше X сделаем» — у нас нет потребности продать вам побольше часов программистов.

Федя — очень крутой техдир, причем мои слабые стороны — его сильные (и наоборот). Я люблю общаться с людьми, а Федя — прогать.

——

Первый клиент, о котором мы расскажем публично — iGooods. Это сервис доставки продуктов из гипермаркетов, родом из Питера. 4000 заказов в день, 250 миллионов рублей оборота в месяц, оценка в 3 миллиарда рублей.

У iGooods 28 программистов, они каждую неделю выпускают новые фичи, бизнес-показатели растут. Нас позвали, потому что: 1) CPO Андрей отвечает не только за продукт, но и за разработку и зашивается; 2) скорость разработки падает, несколько важных проектов тянутся месяцами, даты запуска переносятся; 3) тяжело найти хороших программистов; 4) технический долг копится, команда недовольна.

Я вижу эти сложности почти у каждого IT-проекта. В ближайшие месяцы мы с Федей будем делиться с вами тем, как мы их решаем на примере классной компании. Ура!

Увольняюсь из Пьюр.

Мне трудно и я устал. Дело в отношениях с владельцем Pure, Ромой. Я благодарен Роме за возможность поработать вместе, это были очень интересные полгода, я многому научился.

—

Хочу подвести итог работе в Pure: за эти полгода мы сделали многое для защиты наших пользователей. Борьба со злоупотреблениями — важная часть любого дейтинг сервиса. У нас в Pure, где люди выражаются более свободно, чем в остальном интернете, эта проблема стоит ещё острее.

Плохие пользователи (bad actors) бывают двух типов: те, кто стригут мелкую монету с массовых рассылок и те, кто шантажируют точечно, но на крупные суммы. За эти полгода мы ударили по обоим категориям.

Массовые рассылки происходили из Нигерии (не шутка). Мы прикрыли этот канал и придумали и запустили удобную админку для модерации тысяч фотографий, так что у нас в ленте больше нет странных фотографий с номерами вацапа на них. Мы начали накапливать данные ручной модерации для последующей реализации алгоритмов машинного обучения.

Шантаж происходит так, что вас уводят в не анонимный (читай любой другой) мессенджер, где вы обмениваетесь текстами или фото/видео. Атака может продолжаться часы или даже дни. Злоумышленник деанонимизирует вас по номеру телефона или соцсетям, находит ваших близких и шантажирует вас раскрытием деталей переписки. Для борьбы с этим мы теперь даем отключить таймера у чата (ошейник!) — можно добавить человека в контакты и продолжать общение в Pure.

Внутри чатов Pure мы предупреждаем о том, что собеседник снял скриншот чата и когда он предлагает перейти в другой мессенджер. В способе предупреждений — весь интерфейсный кайф Pure. Это не системное уведомление, а один из 7 классных рисованных персонажей, который вклинивается в переписку и на понятном языке объясняет риски. В последнем релизе мы добавили чумовые стандартные аватарки и отключили возможность загружать картинки из галереи (только фото здесь и сейчас).

Ещё на нас была хакерская атака, которую мы успешно отразили (к сожалению, пока без подробностей).

Две недели назад я нанял в Пьюр ведущего бэкенд разработчика — Антона. За это время Антон вник в проект, сделал так, чтобы серверы не умирали при повторных запросах от клиентов, почти доделал несколько важных задач для борьбы с мошенниками (выпустим большое обновление приложений ещё до Нового года) и наметил план по дальнейшему наведению порядка.

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

Начнем мы с самых основ — с построения удобной среды разработки: настройка рабочего окружения бэкенд-разработчика должна занимать несколько минут, а не дней (docker, клон продакшен базы с вычищенными персональными данными, etc.)

Далее, заменим старую и неподдерживаемую систему фоновых задач gearman на celery и переедем на python3.

А вот дальше начинается круть: полный аудит текущих мобильных приложений и новая версия API, свободная от легаси. Самый сок: сейчас большая часть данных о пользователе хранится в json-ах внутри одной таблицы «users» — мы её распилим на кусочки. Меняем систему доставки обновлений на клиенты с long-polling на вебсокеты (заодно выпиливаем mongo с сотней гигабайт мусора).

Если всё это звучит для вас не как шум, а как интересные задачи и вызов — пишите мне в личку или на [email protected]. Обязательный список: django, celery, aiohttp (можно хотеть изучить, нужен для бэкенда чатов), postgres. Приложите код, который вы считаете лучшим в своей жизни.

Минусы:
- задачи часто меняются
- процесс ещё не устаканен
- нужно много прогать

Плюсы:
- можно участвовать в формулировке задач
- есть тестировщики и хороший сисадмин (devops)
- удаленка
- вы будете работать с АНТОНОМ ШУРАШОВЫМ.

Давно я не писал откровенно, когда плохо.

Сегодня вот хороший разработчик сказал, что уходит в другую компанию. Мне очень больно - думаю, что это из-за моих ошибок.

Одна из озвученных причин - что я игнорировал его несогласие. Он несколько раз говорил, что не видит impact (пользы) в паре задач, а я замял этот вопрос. Не будьте как я, решайте подобные вопросы от разработчиков тем или иным способом не откладывая.

Любое решение лучше, чем игнорирование 🌙