IP-телефония

от 0 руб.

Продуманная связь

для вашего бизнеса

IaaS

По

Облако VMware/Брест

ФЗ-152, SLA 99,99%

HRM

от 8500 руб.

HCM-платформа

для автоматизации HR

IaaS

от 249,95 руб.

Для любых задач

Оплата pay-as-you-go

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

От 200 руб/мес

Передовое

решение

ВКС

от 250 руб/мес

Платформа корпоративных

коммуникаций

BPM

от 12 000 руб/год

Цифровые процессы

с комфортом для людей

  • IaaS

    По

    Облако VMware/Брест

    ФЗ-152, SLA 99,99%

  • HRM

    от 8500 руб.

    HCM-платформа

    для автоматизации HR

  • IaaS

    от 249,95 руб.

    Для любых задач

    Оплата pay-as-you-go

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

    От 200 руб/мес

    Передовое

    решение

  • ВКС

    от 250 руб/мес

    Платформа корпоративных

    коммуникаций

  • BPM

    от 12 000 руб/год

    Цифровые процессы

    с комфортом для людей

  • Kubernetes

    От 5,95 руб / час

    №1 в рейтинге провайдеров

    SLA 99,98%, 152-ФЗ

  • IaaS

    от 490руб./мес

    VMware / ПО РФ

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

  • DBaaS

    От 3,98 руб./час

    №1 в рейтинге DBaaS

    SLA 99,95%, 152-ФЗ, PCI DSS

Kubernetes

От 5,95 руб / час

№1 в рейтинге провайдеров

SLA 99,98%, 152-ФЗ

IaaS

от 490руб./мес

VMware / ПО РФ

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

DBaaS

От 3,98 руб./час

№1 в рейтинге DBaaS

SLA 99,95%, 152-ФЗ, PCI DSS

IBP

по запросу

Универсальная CPM/EPM

self-service платформа

IaaS

По запросу

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

Dedicated, SaaS/PaaS

Low-code

от 667 руб.

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

с ELMA365

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

от 250 руб/мес

Защищенная платформа

коммуникаций

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

Маркет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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