20 Мая 2024 12:24 20 Мая 2024 12:24 |

Поделиться

Что делать, если инфраструктура не успевает за ростом бизнеса?

Главные ИТ-проблемы у растущих компаний

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

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

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

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

Примеры, как нужно и не нужно развивать инфраструктуру

Кейс построения инфраструктуры с дальнейшей поддержкой проекта

Этот кейс из разряда «подумали заранее и сделали правильно». К нам пришел клиент, который хотел масштабировать свой продукт и в первую очередь сфокусировался на его бесперебойной работе. Такое требование неизбежно приводило к развертыванию стабильной микросервисной инфраструктуры.

У них был готовый MVP, уже обкатанный на паре клиентов, но далекий от идеала. Изначально клиент создавал только облачную версию продукта (SaaS) и просил нас сделать инфраструктуру под нее, но рост бизнеса показал, что у пользователей продукта есть потребность в коробочной версии, которая устанавливается непосредственно в инфраструктуру заказчика.

Для этого проекта мы сделали следующие работы:

• Написали ТЗ по построению инфраструктуры для выпуска сервиса, разработанного клиентом, в продакшен. Сервис предполагал две модели: SaaS и установку коробочной версии в инфраструктуру заказчиков клиента.
• Подняли SaaS-версию, сопровождаем ее как инфраструктурная команда, работаем с командой разработчиков клиента.
• Упаковали сервис клиента в коробку, сопроводили инструкциями по внедрению, помогаем клиенту выстроить процесс внедрения в инфраструктуры заказчиков.

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

Кейс, который начинался как аудит надежной работы сайта

Этот кейс наглядно демонстрирует самые распространенные ошибки бизнеса при работе с инфраструктурой. Клиент сформулировал свой запрос так:

«У нас половина инфраструктуры старая, другой половиной мы почти переехали в микрсервисную инфраструктуру (Kubernetes), есть много технических технических сложностей, с которыми непонятно как разобраться. Кроме этого есть большие сложности с наймом: непонятно, как погружать в проект новых DevOps-инженеров, мы уже пробовали, люди в итоге не выдерживали сложности системы и уходили».

Вот что мы сделали, чтобы помочь клиенту:

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

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

Выводы

Итак, что же мы поняли на примере описанных выше и других кейсов:

1. Рост и развитие инфраструктуры должны идти вместе с продуктом — оба этих процесса стоит запланировать.
2. Ведение технической документации очень важно, ведь она фиксирует все изменения в инфраструктуре. Возможно, ее регулярное обновление обернется дополнительными расходами, но зато сократит время решения инцидентов и онбординга новых сотрудников.
3. Процессы и работы в инфраструктуре нужно регламентировать. Очень важно прописать инструкции хотя бы по базовым задачам: развертыванию новых окружений, настройке кластеров, добавлению новых нод и сервисов. Это поможет избежать хаоса в решениях.
4. Коммуникация и обратная связь с ИТ-отделом — это обязательная часть развития бизнеса. Хорошо, если инициативы по улучшению инфраструктуры в компании поощряют. Зачастую инженеры знают, что и как нужно улучшить, но либо заняты текущими задачами, либо боятся, что не будут услышаны, и поэтому молчат.

Внедрив эти советы, вы значительно упростите себе жизнь и сделаете развитие бизнеса более комфортным.

Поделиться

Короткая ссылка