Comments 20
В начале 2006 год, в конце 2020, а в заголовке статьи 5 лет...
За 5 лет от нескольких компов до мульти дата центра. ?
2006 год указан в описании самого проекта ВсеИнструменты, это момент основания компании. А далее (в следующем абзаце) написано:
Когда проект пришёл к нам в 2017 году…
Интересно, сам бизнес в эту пятилетку сильно вырос?
Судя по описанию, до 2017 года все сервисы успешно работали на "нескольких виртуалках".
Да, сильно вырос. Например, есть такая публичная информация.
Верно ли я понял, что 170 программистов и еще 130 айтишников "принадлежащих" ВИ, привлекли еще и стороннюю фирму для "девопса"?
Численность 300 чел. на момент близкий к текущему, на начало сотрудничества было заметно меньше. Плюс в этом составе не надо забывать 1 и 2 линию техподдержки, тестировщиков, аналитиков и менеджмент.
Тестировщики и прочие - это как раз те 130 человек, так ведь?
Я понимаю, что сейчас так принято, но не понимаю... Может, потому-что работаю в нано-команде, а то и вовсе один.
Вот смотрите, их было мало, они позвали вас, вы внедрили "штуку" которая упрощает жизнь IT или экономит деньги бизнеса. Но в результате их стало не меньше, а больше.
Подобная ситуация случилась и с автоматизацией бухгалтерии, как мне кажется: сидели две тетки, работали. Появилась 1С - чтобы было проще, и оп, у нас две тетки, программист, сисадмин и еще пара ребят. Да и тетки уже не справляются.
Да, товаров в магазине стало больше, но это не увеличивает кол-во программистов. Фичи добавляются - но раньше эти фичи успевали добавлять 10 человек. Количество новых фич с годами должно уменьшаться, а не увеличиваться, потому-что всё уже придумано.
Надо поддерживать всякие новомодные штуки, но ведь ребят?, вы же их внедрили, чтобы разгрузить себя, а не нагрузить. Если после внедрения стало сложнее - значит что-то пошло не так?
А как насчет новых целей бизнеса? Штат разработки не связан линейно с имеющимися средствами автоматизации. А вот развитие функционала сервисов, внедрение новых типов складов, усложнение логистики и др. автоматизация не заменит. Вы правы, автоматизация "упрощает жизнь IT или экономит деньги бизнеса" - в случае с DevOps, 130 чел. (в числе которых инженеры инфраструктуры) не превратились в условные 300 чел.
Если что - я ни в коем разе не планирую докопаться до вас, мне действительно непонятно, что происходит с крупным бизнесом. Иногда кажется, что там слишком большие деньги, позволяющие держать лишних людей на всякий случай. А сами ИТ-сотрудники выкладываются меньше, чем они-же пару лет назад.
Про новые цели вы правы. Но ведь с развитием системы работы должно становиться меньше, ибо почти всё сделано. Сотрудники освобождаются и принимаются за новый проект. Они ведь не одноразовые.
Вы пишите - развитие функционала сервисов: некий бизнес придумал сервис, там 20 позиций фич. Прикинули - надо 5 программистов. За год написали все 20 фич.
Работы казалось бы должно быть меньше, - можно парочку сотрудников даже уволить, но штат программистов в этом мире только растет. Почему?
Дальнейшее развитие продукта ведь не должно идти по экспоненте, основной функционал закладывается изначально.
Речь о продуктовых командах, в аутсорсе мне понятна востребованность сотрудников и необходимость зоопарка зачастую ненужных технологий.
Большое спасибо за статью.
Какая у "вас"/проекта типизация траффика? Разделение по ФО (РФ) через geoIP, странам, платёжеспособным зонам (на основе анализа пользователей, совершавших покупки за последние Х дней)? Есть ли heatmap таких платёжеспособных зон и если да - то как с ними работаете в плане повышения эффективности расходования ресурсов на такие зоны, также от расходов на рекламу до расходов на логистику в них.
Проводите ли анализ "сезонности" траффика внутри дня и недели? Возможно, в зависимости от продолжительности резко возросшей нагрузки, имеет смысл заранее запустить резервные мощности в минимально необходимом объёме и за полгода-год сравнить hit rate такого подхода, помогает ли он повысить доступность сервисов или экономить на чём-то.
Проводите ли анализ стоимости рисков недоступности и восстановления микросервисов во времени и деньгах, а также есть ли схемы дополнительного частичного резервирования таких сервисов на случай сложных/нестандартных проблем? Например, с самим kubernetes или его обновлением, либо с системой сбора и анализа метрик и логов, либо при глобальных сетевых проблемах в рамках одного сервис-провайдера и его геозон датацентров.
Пробовали ли вы проводить тренировки по полной миграции всей инфраструктуры на другие сервис-провайдеры, к примеру, для оптимизации расходов на инфраструктуру? Если да - было бы интересным узнать как всё это происходило, какие инструменты использовали, какие проблемы возникали и прочее.
Как у вас реализован мониторинг выполнения SLO? Это скрипты по метрикам из прометея или что-то более сложное? Часто к глобальным метрикам бизнес-инфраструктуры привязывают различные алерты, которые, с учётом ранее оцененной стоимости, могут генерировать различные алерты для различных источников их возможного решения, вплоть до "сопровождения" инцидента в системе глобального мониторинга всего проекта.
Есть ли у вас версионирование API и список поддерживаемых версий? Если да - как вы с ним живёте и работаете за время развития продукта.
К примеру, если взять информацию по code coverage и наборы текущих тестов с привязкой к версионности API, то можно сформировать картину по каждому тесту или группе тестов, какие участки кода дольше всего живут и какие отвечают за бОльшее покрытие поддерживаемых версий. В итоге, можно даже попробовать построить стоимость участков такого кода, определить их важность в деньгах/времени и это далее учитывать при оценке сложности/стоимости новых задач для разработчиков, как корректируемый коэффициент предполагаемой стоимости от 1 до 10, либо "не ниже чем". Потенциально, это может существенно помочь в оценке времени и стоимости работ, немного упростить менеджмент задач, к примеру, заранее распределяя заведомо сложные на соответствующих разработчиков.
С помощью анализа более-менее крупных участков кода, как самого продукта, так и набора тестов для них всех уровней, можно, к примеру, с помощью скрипта проанализировать через простейший git blame список авторов кода, наиболее актуальных по времени и активных во вкладе участников, эту информацию уже использовать вплоть до предложения списка участников митинга по новым задачам, затрагивающим "старые". Со временем, если "старый" разрабочик всё дольше не имел отношения к определённому участку кода проекта - он всё реже станет привлекаться к обсуждению новых задач, связанных со старым кодом, тем самым, будет происходить оптимизация времени разработчика как на митинги, так и на оценку новых задач (в зависимости от того, что за подход в оценке задач используется).
Всем ли вас устраивает MySQL и если нет - как вы на уровне инфраструктуры и микросервисов проводите подготовку по изоляции проекта от хранилища и переходу на какое-то другое, к примеру, на PostgreSQL? Если, конечно, такая задача вообще имеется на горизонте. Есть ли дробление на типы данных для удобства и ускорения восстановления в случае ЧП, либо это какой-то "монолитный" бэкап, снимающийся с readonly хостов в периоды слабой нагрузки?
Почему решили продолжать работать с rabbitmq, с учётом уже прилично выросшего масштаба проекта? Всем ли он вас устраивает и нет ли желания переехать на что-то другое, типа kafka/flink/etc?
Спасибо.
Спасибо за большой вопрос) попробую ответить коротко по порядку:
Heatmap есть, используется для анализа географии открытия новых торговых точек.
Анализ траффика по сезонности и неделя к недели есть, учитывается при планировании подготовки сервисов к росту нагрузки. Начиная с ковида 2020 года, год к году сильно отличается и необходимо делать поправку. + у нас не такой бизнес когда может произойти резкий всплеск траффика даже в распродажи, не тот сегмент товаров.
Анализ проводится при написании посмортемов и есть деление сервисов на критичные и не критичные для бизнеса. Считаем стоимость минуты простоя от выручки, либо потерянные заказы.
По поводу резервирования, большинство сервисов одновременно работают в 3 ДЦ и это также требование для разработки новы , трафик идёт сразу в 3, в случае инцидента трафик снимается с 1го ДЦ или сервиса в этом ДЦ и дальше уже разбираемся с проблемой. То же самое касается обновлений сервисов, раскатывать можем на 1ДЦ и в случае отсутствия проблем, продолжать с другими.Нет, сейчас инфраструктура это colocation + cloud под определённые сервисы.
Про SLI/SLO/SLA: Grafana + Prometheus + алерты на команды в зависимости от их графика дежурства на сервисе и эскалации. Влияние на бизнес-метрики считаем, но пока это больше при написании посмортемов сводим вместе и считаем конечное влияние на бизнес например в потерянных заказах, подведенных клиентах, относительно того когда обещали клиенту доставить заказ, ....
Mysql полностью устраивает для тех задач где используется, кроме наверное того что это не версия 8.x, а 5.7.
Касаемо подготовки по изоляции данных - мы стараемся уйти от зависимости конкретной РСУБД, в новых проектах заставляя организовывать всю логику работы внутри приложения. Но это очень сложно сделать с монолитами.
Касаемо восстановление - дробления нет, восстанавливается все целиком. Есть реплики, где можно снять бэкап приостановив репликацию.
PostgreSQL + Patroni у нас тоже есть, из крупных инсталляций это WMS и CRM, работает так же на мультицод.Про Rabbitmq: Мы уже успели перейти на Kafka, в статье это не затронуто, так как делалось отдельно от ребят из Фланта
Про 170 разработчиков Вы зря написали. Это тот случай когда "у семи нянек дитя без глаза". Что сайт, что мобильное приложения очень далеки от совершенства, подозреваю из этих 170 работает нормально человек 10 и те в основном поддержкой работы сайта в основном заняты... Сделайте уже нормально работающее избранное (списки так и не работают), возможность добавлять производителя в избранное, сохранение настроек в мобильном приложении, нормальную настройку уведомлений (на сайте их вообще нет). Это только что сходу пришло на ум.
с чем я полностью согласен, так это с тем, что должен быть план восстановления. Желательно на бумаге, с приложением в виде контактов (субчики, программисты, провайдеры и.т.д.) и с вариантами развития событий. Ибо, как встают мозги раком во время факапа у самых продвинутых я за 30 лет наблюдал не раз. И чем больше структура, тем геморней составлять такой план, многие забивают, а потом отгребают.
Наши 5 лет с инфраструктурой «ВсеИнструменты.ру»: от нескольких ВМ до отказоустойчивого решения в трёх дата-центрах