СЭД

от руб.

IaaS

от 490руб./мес

VMware / ПО РФ

SLA 99,95% Pay-as-you-go

Kubernetes

от 5.51 руб/час

Kubernetes as a Service

Отказоустойчивые кластеры, быстрый запуск, удобное управление

BPM

17 000 руб On-Prem

Low-code BPM

для комплексной автоматизации

IaaS

По запросу

По вашим правилам

Dedicated, SaaS/PaaS

ВКС

Стоимость по запросу

Тариф IVA MCU

Kubernetes

от руб.

  • IaaS

    от 490руб./мес

    VMware / ПО РФ

    SLA 99,95% Pay-as-you-go

  • Kubernetes

    от 5.51 руб/час

    Kubernetes as a Service

    Отказоустойчивые кластеры, быстрый запуск, удобное управление

  • BPM

    17 000 руб On-Prem

    Low-code BPM

    для комплексной автоматизации

  • IaaS

    По запросу

    По вашим правилам

    Dedicated, SaaS/PaaS

  • ВКС

    Стоимость по запросу

    Тариф IVA MCU

  • Kubernetes

    от руб.

  • Корпоративный портал

    от 500 000 руб.

    Российское решение

    аналог Microsoft Sharepoint

  • Корпоративные мессенджеры

    Стоимость по запросу

    Тариф IVA One

  • Операционные системы

    5 280 руб.

    BaseALT Альт Рабочая станция 10

    архитектура 64 бит

Корпоративный портал

от 500 000 руб.

Российское решение

аналог Microsoft Sharepoint

Корпоративные мессенджеры

Стоимость по запросу

Тариф IVA One

Операционные системы

5 280 руб.

BaseALT Альт Рабочая станция 10

архитектура 64 бит

IaaS

По запросу

ФЗ-187, КЗ-1 ФЗ-152

УЗ-1, ГОСТ 57580.1

СЭД

от руб.

Low-code

от 833 руб.

Цифровая трансформация

с ELMA365

СЭД

17 000 руб On-Prem

Цифровая трансформация

с ELMA365

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

Маркет

К нам в ITSumma приходят клиенты в разном состоянии, на разных этапах развития. Раньше это были в основном небольшие магазины с монолитной инфраструктурой, теперь же проекты стали разнообразнее: финтех, сервисы, магазины, новости. Как следствие, инфраструктуры, с которыми мы работаем, становятся крупнее и запутаннее. У многих компаний растет бизнес, а вместе с ним и инфраструктура. При этом мы заметили, что рост инфраструктуры часто не поспевает за бизнесом. Самый распространенный запрос, с которым к нам приходят, звучит так: «Мы выросли/пришел большой трафик на акцию/пришло много людей с рекламы, и инфраструктура не выдержала нагрузки». И однажды мы задались вопросом, почему же так происходит.

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

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

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

Можно выделить одну общую для любой отрасли проблему: плохо налаженную коммуникацию между бизнесом и техническими подразделениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

erid:LjN8KMUGvРекламодатель: ООО "СУММА АЙТИ"ИНН/ОГРН: 3810053581/1083810003166Сайт: https://www.itsumma.ru/

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