Рассказываем, как переписали почти всё Android приложение и что из этого вышло (для программистов).
Спойл: статьи открываются быстрее, крешится меньше, программировать проще.
Ура Андроиду!
будни
В чем заключается работа технического директора? Обычно я отвечаю отрывочно или углубляюсь в какой-то аспект профессии, который интересует меня в тот момент.
Мы с Федей уже почти месяц вместе составляем системный ответ на этот вопрос. Для командной работы мы завели личную базу знаний (что-то вроде своей википедии) в 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. У нас есть отличная вакансия для рубиста в Питере.
Обещал — рассказываю: «как я передал должность техдира Медузы».
Шутили вчера с женой, что Боря заведет свой тг-канал и выпустит дисс «как Самат нас бросил, или не всё так радужно» 🙈
Мы в 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.
Мы у себя в компании протестировали ИИ-помощники для программистов. По результатам, добавили Github Copilot в список инструментов, которые оплачиваем всем нашим сотрудникам — он ускоряет написание рутинного кода. Цитирую коллегу:
Когда работаешь с копилотом, кажется, что он помогает нормально, но без вау. Зато когда его выключаешь, то ловишь себя на мысли, что пишешь какую-то фигню, вместо которой можно было просто табнуть.
Ещё из интересных инструментов, которыми пользуются коллеги:
- Phind: классный ассистент для программистов, которому можно позадавать вопросы. Доступен без VPN, никогда не отваливался и, что важно, дает ссылки на источники;
- Machinet: плагин, окно чата, которое видит весь твой проект. В нем можно написать «вот есть ручка //products, напиши такую же только для //orders и сделай такие же тесты» или «почини N+1 запросы в методе getusers на открытой вкладке»
Если ничем таким ещё не пользуетесь — рекомендую попробовать!
Мы с Федей ищем технического директора в igooods себе на замену.
igooods — это доставка продуктов из гипермаркетов. Сотни тысяч клиентов, тысячи заказов в день, миллиард оборота в месяц. 36 городов России. В партнерах — Метро, Лента, Призма, Вкусвилл, Ашан, Глобус, Карусель, Окей.
Техническая команда — 31 человек. Под капотом рельса и реакт, нативные мобильные приложения для iOS и Android.
Вы заберёте разработку, которая находится в процессе трансформации от небольшой уютной тусовки к машине по зарабатыванию денег. За последние полгода производство стало работать чётче, но до швейцарских часов ему пока далеко — много вещей делаются на ручном контроле. Вам предстоит выстроить QA, доукомплековать продуктовые команды, до конца перейти на сервисную архитектуру (цель — через полгода перестать писать код в монолит) и создать систему управления техдолгом.
Вторая задача — подчинить разработку бизнесу, работая бок о бок с CPO. Каждый джуниор-фронтендер должен знать, на какую метрику повлияет задача, которую он сейчас делает, а любая гипотеза про деньги должна проверяться не дольше трёх недель.
Мы с Федей запустили эти процессы, но чтобы завершить работу, нужно жить в Питере.
Команда прекрасная, но это не значит, что вам не придется много работать руками. Оно того стоит — вы выстроите первоклассную разработку в одном из крупнейших сервисов доставки продуктов в России.
Офис в Питере, помощь с переездом. Подчинение напрямую владельцу бизнеса; основной рабочий партнер — CPO Андрей Родин.
Пишите краткий рассказ о себе мне в личку или на [email protected].
Я обожаю диаграммы. Рисовать их на доске или на бумажке и одновременно обсуждать с программистами. Это мой способ разобраться самому и объяснить что-то сложное другим.
На видео — реальные схемы разработки нового проекта для igooods. В статье — обзор классных инструментов и примеры из жизни.
Раньше сайт Медузы грузил шрифты так, что текст прыгал на доли секунд при загрузке страницы. Это было нежелательным побочным эффектом оптимизации сайта для мобильных читателей, которые попали на Медузу впервые. «Прыжки» подбешивали внимательную аудиторию в десктопе.
Мы переработали схему. Теперь, при первом открытии сайта показываются системные шрифты, а при всех следующих заходах — наши. Без каких-либо дерганий.
Оптимизация веба для скорости — бесконечно большая и интересная тема. Мы пока выбираем 80% процентов профита, достигаемые первыми 20% труда.
Утренняя кулстори. Мой рижский провайдер берет внешний интернет у Lattelecom. Это местный аналог Ростелекома, крупнейший в Латвии, остатки советского наследия.
Так вот, недавно мы заметили, что некоторые заблокированные Роскомнадзором сайты не открываются и в Риге тоже. Выяснилось, что часть маршрутов у Латтелекома идут через русских провайдеров, которые не заморачиваться и блокируют доступ и на транзитном уровне.
После нашей просьбы Латтелеком перестроили маршруты для указанных адресов, обойдя злобных буратин, но сколько таких адресов я не заметил?
Это очень похоже на блокировку YouTube в 2008 году, когда Пакистан объявил, что ютуб нынче хостится в Исламабаде и большая часть сетевого оборудования им поверила.
Сложновато с цифровым суверенитетом в системе, придуманной для максимальной отказоустойчивости (в случае советской ядерной атаки, в том числе).
Наш ведущий фронтендер Миша Бурмистров сделал чеклист по веб-безопасности для фронтенд-разработчиков компании.
Хвастаюсь!
Опубликую ещё первый комментарий Миши к этому посту (не видны публично):
Было бы удобно, если бы ко всем пунктам списка были приложены материалы, но поиск/фильтрация материалов это работа, которую я не готов сейчас делать. Кроме того, у всех разные предпочтения в плане формата контента — кто-то любит статьи на русском, кто-то видео на английском и т. п. Все темы из списка довольно известные — уверен, вам не составит труда найти по ним информацию. Можете делиться понравившимися материалами в комментах.
А чтобы почитать остальные комментарии — придется устроиться к нам на работу :)
Признаюсь, я и сам не знаю некоторых аббревиатур 🙈
Разработчики, которые думают о безопасности — единственный способ делать безопасные приложения. Никакие отделы безопасности не спасут, если разработчикам пофиг. Так же, как и с тестированием — о качестве должны думать все разработчики, а не только «специалисты»!
В общем, горжусь и хвастаюсь!
