Главные ИТ-проблемы у растущих компаний
С ходу можно выделить одну общую для любой отрасли проблему: плохо налаженную коммуникацию между бизнесом и техническими подразделениями. Маркетинг, прибыль, продукт, бренд и продажи довольно часто волнуют менеджмент больше технической стороны продукта, о которой думают как раз тогда, когда что-то идет не так. Если продукт цифровой, в фокусе внимания чаще оказывается разработка, новые фичи, дизайн, пользовательский опыт, а вот инфраструктура, на которой развернут и работает продукт, как будто нелюбимый ребенок - о нем вспоминают только тогда, когда он получил двойку.
Далеко не всегда бизнес планирует развитие инфраструктуры, скорее это происходит уже после инцидентов, из-за которых было потеряно много денег. Да и стоимость простоя наши клиенты иногда узнают постфактум, когда сбой уже произошел. Обычно тогда экстренно инициируются изменения, и происходит следующее.
Коллеги экстренно что-то исправляют, «подсовывают табуретки и вбивают костыли», чтобы система не падала. В этом процессе часто используют и новые технологии, что приводит к своеобразному зоопарку, когда на разных контурах одного проекта внедрены разные решения, и никто не знает, как это функционирует. При следующем сбое в работе инфраструктуры процесс не просто повторяется, а выходит на другой уровень, ведь видовое разнообразие решений растет, а система и взаимосвязи внутри нее значительно усложняются с каждой итерацией.
Как результат - в системе поселяется хаос, в котором никто не может разобраться. Поэтому мы часто оказываемся для клиентов источником не только технических знаний, но и знаний об организации процесса. Как научить команду работать с инфраструктурой, как с кодом, управлять знаниями о проекте, вести внутреннюю документацию, внедрять практики повышения надежности сайта и анализ инцидентов. Как улучшить наблюдаемость (обзервабилити) системы, как перестать тонуть в текучке и начать работать с отложенными задачами не только в разработке, но и в инфраструктуре, как выстроить онбординг для новых людей и новых объектов инфраструктуры - на эти вопросы мы помогаем ответить и выработать процессы.
Примеры, как нужно и не нужно развивать инфраструктуру
Кейс построения инфраструктуры с дальнейшей поддержкой проекта
Этот кейс из разряда «подумали заранее и сделали правильно». К нам пришел клиент, который хотел масштабировать свой продукт и в первую очередь сфокусировался на его бесперебойной работе. Такое требование неизбежно приводило к развертыванию стабильной микросервисной инфраструктуры.
У них был готовый MVP, уже обкатанный на паре клиентов, но далекий от идеала. Изначально клиент создавал только облачную версию продукта (SaaS) и просил нас сделать инфраструктуру под нее, но рост бизнеса показал, что у пользователей продукта есть потребность в коробочной версии, которая устанавливается непосредственно в инфраструктуру заказчика.
- Написали ТЗ по построению инфраструктуры для выпуска сервиса, разработанного клиентом, в продакшен. Сервис предполагал две модели: SaaS и установку коробочной версии в инфраструктуру заказчиков клиента.
- Подняли SaaS-версию, сопровождаем ее как инфраструктурная команда, работаем с командой разработчиков клиента.
- Упаковали сервис клиента в коробку, сопроводили инструкциями по внедрению, помогаем клиенту выстроить процесс внедрения в инфраструктуры заказчиков.
Что получил клиент: услуги по внедрению продукта в инфраструктуры заказчиков, сопровождение технической части своей инфраструктуры, реакцию на инциденты от нашей команды. А также помощь в росте и развитии - когда у клиента возникает потребность в расширении, усложнении системы, мы подбираем наиболее подходящие инструменты и прорабатываем процессы, которые дают возможность сосредоточиться на развитии бизнеса.
Кейс, который начинался как аудит надежной работы сайта
«У нас половина инфраструктуры старая, другой половиной мы почти переехали в микрсервисную инфраструктуру (Kubernetes), есть много технических технических сложностей, с которыми непонятно как разобраться. Кроме этого есть большие сложности с наймом: непонятно, как погружать в проект новых DevOps-инженеров, мы уже пробовали, люди в итоге не выдерживали сложности системы и уходили».
- Осмотрели всю систему, разобрались во взаимосвязях сервисов. Нашли слои попыток сделать лучше - разные инструменты, которые клиент пробовал применять для упрощения работы, потом решал отказаться, но не убрал из системы. Итог - несколько контуров одного и того же приложения, каждый из которых настроен по-разному, разными инструментами.
- Разобрались, как сейчас реализована отказоустойчивость: от масштабирования и резервирования до бэкапов.
- Осмотрели и изучили систему мониторинга и алертинга.
- Прочитали имеющуюся документацию по проекту.
- Обсудили с клиентом увиденное, выяснили его бизнес-задачи, помогли сформулировать требования к системе.
- Разработали план модернизации и унификации инфраструктуры с учетом бизнес-задач и требований.
- Разработали концепт внутренней документации и процесс ее актуализации.
- Привели в порядок внутреннюю документацию проекта согласно разработанной концепции, помогли с внедрением процесса по актуализации и подключению новых сервисов.
- Разработали карту покрытия системы мониторингом и процессы по реакции на инциденты, их анализу и разработке инструкций по устранению неполадок (ранбуков).
- Помогли с внедрением системы мониторинга, совместно с командой клиента обкатали процессы по реакции на инциденты.
В итоге клиент получил гораздо более понятную систему, исправление многих сложностей, с которыми сталкивался. А также настроенные процессы по расширению системы, внедрению новых сервисов, работе с инцидентами в системе. Документация и общая логика процессов позволяет относительно легко расширять команду вслед за ростом системы.
Выводы
- Рост и развитие инфраструктуры должны идти вместе с продуктом - оба этих процесса стоит запланировать.
- Ведение технической документации очень важно, ведь она фиксирует все изменения в инфраструктуре. Возможно, ее регулярное обновление обернется дополнительными расходами, но зато сократит время решения инцидентов и онбординга новых сотрудников.
- Процессы и работы в инфраструктуре нужно регламентировать. Очень важно прописать инструкции хотя бы по базовым задачам: развертыванию новых окружений, настройке кластеров, добавлению новых нод и сервисов. Это поможет избежать хаоса в решениях.
- Коммуникация и обратная связь с ИТ-отделом - это обязательная часть развития бизнеса. Хорошо, если инициативы по улучшению инфраструктуры в компании поощряют. Зачастую инженеры знают, что и как нужно улучшить, но либо заняты текущими задачами, либо боятся, что не будут услышаны, и поэтому молчат.