Предотвращение следующего отключения облаков: внутри архитектуры современных платформ ITSM

Отключение перерывов, которое нарушает полеты летом 2024 года. Год спустя Google Cloud взял на себя носовой Если раньше были какие -либо сомнения, эти события доказали это: ни одна техническая компания не слишком велика, чтобы терпеть неудачу - и когда они это делают, последствия являются огромными. По мере того, как предприятия быстро переходят в облако и в значительной степени полагаются на инструменты генерации кода, сохраняют контроль над изменениями в коде, ИТ-инфраструктуре и предотвращение поломки всего системы больше не является обязательным. Это важно. По мнению многих экспертов, в этой новой технологической реальности внимание к практике управления услугами может спасти от неудач ИТ. Системы ITSM и ESM, которые внедряют эту практику, становятся центральными инструментами для управления бизнес -операциями и обеспечения их устойчивости и зрелости. Эти системы позволяют централизованно управлять изменениями в программном обеспечении и инфраструктуре, мониторинга процессов и автоматически обнаруживать потенциальные риски, прежде чем они перерастают в основные инциденты. Это делает их жизненно важной связью в защите предприятий от крупномасштабных сбоев.

Dmitry Malygin - инженер -программист, архитектор и технический лидер с более чем 12 -летним опытом. Он был назван одним из 40 наиболее влиятельных цифровых экспертов страны и был признан экспертным жюри национальных лидеров цифровых цифровых технологий за его выдающийся вклад в разработку предпринимаемых цифровых платформ. Он является автором и руководил разработкой платформы ESTM/ESM предприятия, развернутой в ведущих национальных банках, в том числе с международным присутствием, в совокупности более 30 миллионов клиентов. Его передовые решения составляют основу автоматизированного управления обслуживанием и процессами в распределенных и критически важных инфраструктурах.

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

Дмитрий, ИТ -системы крупнейших технологических компаний создаются с использованием передовых практик DevOps, автоматизации и инструментов мониторинга. По вашему мнению, как архитектор и разработчик, почему они остаются настолько уязвимыми для неудач?

Современные системы, такие как Google Cloud Platform, Spotify или Snapchat, создаются как сложные, многокомпонентные и распределенные решения, которые значительно усложняют их разработку, обслуживание и эволюцию. В экосистемах с тысячами микросервисов точки сбоя могут возникать на различных уровнях - от сети и базы данных до сторонних интеграций. Единственный сбой на периферии может вызвать каскадную ошибку по всей системе. Человеческий фактор также играет значительную роль. Сбои часто возникают на пересечении обязанностей разных команд, особенно когда нет сквозного, формализованного процесса управления изменениями, будь то код или инфраструктуру.

Широкое использование инструментов автоматизации и генерации кода добавляет дополнительную сложность. Слепое доверие разработчиков к генераторам кода иногда приводит к тому, что критические ошибки, проникающие в производственную среду незамеченными, несмотря на формально устоявшиеся процессы CI/CD. Эта проблема становится особенно острой под давлением жестких сроков. Следовательно, разработка и поддержание таких систем требуют передовых механизмов для контроля, проверки и проверки, которые будут интегрированы на каждом этапе жизненного цикла, но без ущерба для скорости развития. Надежность системы не только о том, чтобы избежать сбоев - это в равной степени о том, как быстро система может отскочить назад и ограничить ущерб, когда что -то идет не так.

Могут ли ярлыки, взятые на ранних этапах, вернуться, чтобы вызвать проблемы после запуска системы? Из того, что вы видели, сколько таких вещей, как стремительные сроки или неясные требования формируют решения архитектуры и влияют на конечный продукт?

Тяжелые сроки в сочетании с высокой рабочей нагрузкой, а также неопределенностью в бизнес-требованиях, несомненно, иногда оказывают довольно негативное влияние на качество доставленного кода, даже если сам процесс выпуска хорошо зарекомендовал себя. Прежде всего, это вопрос управления проектами. При расстановке приоритетов задач, управления отставанием и тестирования тестирования все важны, реальные условия редко совершенны, а компромиссы часто неизбежны. В одном проекте для клиента Fortune Global500, где я был техническим лидером, мы столкнулись с строгим сроком запуска MVP (минимальный жизнеспособный продукт). Архитектурно, было очевидно, что асинхронная модель связи между компонентами была подходящей. Но крайний срок был напряжен, и бизнес хотел его быстро - поэтому мы изложили риски и пошли дальше с синхронной интеграцией, даже зная, что это не идеально. В результате, некоторое время после запуска, мы обнаружили, что система не может обрабатывать пиковые нагрузки, что привело к временной недоступности.

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

По вашему опыту, какие меры, которые могут значительно снизить вероятность ошибок в коде и ИТ -инфраструктуры, а также минимизировать риск неудач, чаще всего недостаточно используются?

Исходя из моего опыта, существует несколько мер с сильным потенциалом для улучшения контроля доставки, качества кода и стабильности инфраструктуры ИТ, которые часто не полностью используются. Во -первых, интеграционное тестирование и комплексное тестирование системы. Команды пишут модульные тесты и сохраняют высокие номера тестовых покрытий, но когда дело доходит до проверки того, как различные части системы на самом деле разговаривают друг с другом, или как они обрабатывают внешние API, вот где появляются пробелы. Во -вторых, мониторинг часто ограничивается основными показателями, что снижает его эффективность. Многие настройки по -прежнему недооценены сценариями прогнозирования, несмотря на их потенциал значительно повысить устойчивость системы. Кроме того, я часто наблюдаю за трудностями, сталкивающимися с трудностями с внедрением инфраструктуры в качестве кода (IAC) на практике, в первую очередь потому, что код, ответственный за обеспечение и настройку инфраструктуры, редко проверяется с той же строгостью, что и код приложения.

Это может привести к тому, что при запуске серверов с неправильными настройками безопасности или неправильно настроенными базами данных. Я также выделил бы процессы ITSM, которые часто реализуются официальным и изолированным образом, без тесной интеграции с разработкой и автоматизацией. При интеграции в трубопровод DevOps даже один процесс, такой как управление изменениями, может значительно улучшить баланс между контролем и скоростью доставки. Такая интеграция позволяет использовать запросы на изменение - формальный процесс контроля изменений в коде, инфраструктуре и конфигурациях, помогая обеспечить соблюдение и поддержку оценки риска.

Благодаря практическому лидерству в создании платформы управления услугами, вы получили глубокое техническое понимание того, что нужно, чтобы сохранить стабильные и устойчивые крупные ИТ-системы. Как ваша система работает за кулисами, чтобы безопасно управлять изменениями, уклоняться от рисков в доставке и сохранять все без сбоев?

Платформа, которую я разработал, основана на основе ITIL и построена вокруг принципов ITSM (управление ИТ -услугами), предлагая систематический подход к управлению ИТ -услугами. Кроме того, он распространяется на модель ESM (управление услугами Enterprise), позволяя применять эти принципы во всех бизнес -единицах, а не только это. Платформа построена с модулями, которые помогают снизить риск возникновения проблем, связанных с выпуском, и обеспечивают надежные услуги. Одним из наиболее важных частей является модуль управления изменениями - это то, что поддерживает каждое изменение в коде или инфраструктуре под контролем, от начала до конца. Можно связать систему с трубопроводом CI/CD, чтобы критические развертывания блокировались автоматически, если нет утвержденного запроса на изменение. Еще одна ключевая часть - модуль управления инцидентами, который вызывает проблемы, отслеживает их, выясняет их тип и помогает быстро решить, чтобы избежать простоя.

Подключаясь к системам мониторинга, такими как Prometheus и инструменты наблюдения, такие как DataDog и Grafana, инциденты создаются автоматически, когда появляются необычные метрики, активируя действия Set Runbook для решения проблем. Одним из ключевых компонентов платформы является CMDB (база данных управления конфигурацией), в которой хранится информация об элементах конфигурации (CI) и о том, как они относятся друг к другу. Эта база данных используется для создания графика зависимости, что позволяет анализировать потенциальное влияние изменений и блочных выбросов, которые представляют высокий риск. Благодаря интеграции этих модулей в одну платформу становится возможным значительно улучшить стабильность высвобождения, уменьшить количество связанных с изменением инцидентов, более низкого среднего времени до восстановления (MTTR) и обеспечить скоординированные усилия по инженерным группам во время инцидентов.

Однако, как отмечалось в отчете Форрестера «Будущее ITSM и ESM», платформы управления услугами, как и любые сложные системы, становятся все труднее и дорогостоящими для настройки. Основываясь на вашем опыте, с какими проблемами сталкивались ваши корпоративные клиенты чаще всего, и как они влияли на ваши архитектурные решения?

При создании платформы мы с командой провели углубленные интервью с корпоративными клиентами, чтобы понять их основные разочарования. Один технический директор сказал нам прямо: «Я не хочу реструктурировать бизнес -процессы моей организации только для установки платформы управления услугами». Это застряло со мной. Стало ясно, что настройка - способность системы адаптироваться к существующим процессам - была одним из наиболее важных требований. Мы также видели проблемы с масштабируемостью у компаний с более чем 10 000 сотрудников - в одном случае система не могла справиться с одновременными запросами из нескольких бизнес -единиц, потому что она была построена как монолит и не имела надлежащего горизонтального масштабирования. В результате даже обычная обработка билетов замедлилась до ползания в часы пик. Еще одной общей болезнью была интеграция.

Например, один клиент нуждался в синхронизации в режиме реального времени с системами HR и CRM, но их предыдущая платформа требовала для него пользовательские сценарии. Мы знали, что должны были рассмотреть это с помощью открытых API и встроенных разъемов. Мы рассмотрели это понимание в нашей архитектуре. В конечном итоге мы выбрали подход с низким кодом, чтобы сделать систему гибкой и доступной, и добавили прогнозирующую аналитику, чтобы помочь автоматизировать повторяющиеся процессы.

Когда вы оглядываетесь назад, какой был самый сложный технический выбор или архитектурные препятствия, которые действительно проверили вас? Были ли вы какие -либо стратегические технические решения, которые вы приняли, которые впоследствии оказались критически важными для эффективности или устойчивости системы?

Одной из самых больших проблем, с которыми я столкнулся, было справляться с растущей нагрузкой на модули, которые управляют изменениями и выпусками. Из -за некоторых бизнес -соображений они были первоначально разработаны как монолит. В начале я осознал, что этот дизайн станет узким местом по мере масштабирования спроса пользователя. Я возглавил инициативу разделить модули на отдельные микросервисы, выравнивая две команды разработчиков в условиях жесткой сроки доставки. Рефакторинг позволил самостоятельно развивать модули и масштабировать их в соответствии с их профилями нагрузки, что устраняет точки дросселя, вызванные монолитным подходом. Кроме того, чтобы сохранить контроль над системой под высокой нагрузкой, я отстаивал подход первого наблюдения и возглавил развертывание расширенного стека мониторинга, используя Prometheus, Grafana и Elk. Это помогло нам рано поймать регрессии и уменьшить время исправления ошибки на 3 раза.

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

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

Одним из наиболее заметных достижений было сокращение нескольких ключевых показателей ITSM/ESM, особенно достигнув 30% падения в MTTR (среднее время для разрешения), что охватывает полный процесс инцидента - от обнаружения проблемы для решения и закрытия его. Низкий MTTR особенно важен для таких секторов, как финансы, здравоохранение и транспорт. Это улучшение стало возможным благодаря моему решению, которое реализует подход «сдвиг лежать»: интеллектуальный портал самообслуживания, позволяющий пользователям сами решать общие проблемы, от сброса пароля до доступа к запросам и перезапуска услуг. В результате количество запросов, обработанных поддержкой первой линии, было уменьшено примерно на 20%, что позволило командам перенаправлять ресурсы на более сложные и критические инциденты. Кроме того, мы достигли сокращения AFRT на 20% (среднее время первого отклика) по сравнению с устаревшей системой.

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

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

Чтобы координировать работу более чем 10 команд разработчиков с 100 инженерами и сохранить постоянные темпы поставки с высоким качеством продукта, я представил архитектурную и организационную модель на основе трех основных принципов. Во -первых, команды были структурированы вокруг модульной архитектуры системы, следуя закону Конвея: каждая команда владела отдельным функциональным модулем, совместимым с конкретной бизнес -доменой. Я сосредоточился на установлении четких контрактов API и способствовал сдвигу в сторону асинхронного общения, что помогло нам масштабировать более эффективно и ослабил меж командные зависимости. Затем я собрал специальную команду платформ, чтобы позаботиться о общих вещах - чтобы команды продуктов могли сосредоточиться на реальных потребностях бизнеса, избежать переосмысления колеса и быстрее отправлять. В -третьих, я представил архитектурный совет и регулярные сессии дизайна.

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

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

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

Платформа может быть развернута как в инфраструктуре поставщика программного обеспечения, так и в помещениях клиента. Он включает в себя модуль управления изменениями, который регулирует процесс изменения и снижает риски, связанные с развертыванием нестабильного кода. Когда автоматически генерируемый код входит в трубопровод CI/CD, система может автоматически создавать запрос на изменение (CR), если он настроен, который запускает консультативный совет по изменению (CAB), чтобы принять окончательное решение о доставке кода. Это решение учитывает контрольные списки, результаты сканирования SAST/DAST, наличие «галлюцинированных» зависимостей и других факторов. Планы отката также рассматриваются. Если возникает ошибка, инцидент автоматически создается и регистрируется на платформе, сразу же запуская команду технической поддержки. Таким образом, платформа ITSM/ESM обеспечивает контролируемый и безопасный процесс доставки и эффективно помогает предотвратить сбои, такие как те, которые испытывали Crowdstrike и Google Cloud.

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

Премия была предоставлена после процесса конкурентного отбора, проведенного независимой группой отраслевых экспертов. После первоначального этапа проверки материалы участников были оценены на основе множества критериев, включая уровень инноваций, технического глубины, общего воздействия, стоимости бизнеса и других соответствующих показателей. Моя заявка получила самый высокий общий балл среди участников и была признана лучшим в двух отдельных номинациях. Экспертная группа подчеркнула широкое влияние моего решения ITSM/ESM на повышение эффективности бизнес -операций в крупных организациях. Жюри специально подчеркнуло мой вклад в качестве разработчика, архитектора системы и руководителя команды - мои предлагаемые технические подходы сформировали решение, которое оказалось эффективным в проектах с участием основных банков. Ключевые факторы в оценке включали использование асинхронной архитектуры микросервиса, прогнозирующей аналитики, гибкой конфигурации бизнес -логики и взаимодействия пользователей Omnichannel.

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

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

Каждый хитрый инженерный вызов оставляет вас с чем -то новым, и я всегда чувствовал, что обмен этими идеями - это то, как я могу внести свой вклад в эту область. Некоторые из моих исследований, которые вы можете найти в Google Scholar, поступают прямо из практического инженерного опыта. Это привлечено внимание, потому что он имеет дело с реальными проблемами, которые команды сталкиваются при масштабировании систем и предлагают исправления, которые фактически работали на практике. Одна из таких статьи, методология оценки фреймворков JVM для разработки платформ автоматизации ITSM/ESM, основанной на автоматической производительности, представляет собой структурированный подход к сравнению фреймворков Java, таких как Spring Boot, Micronaut и Quarkus. Методология была разработана во время создания платформы управления корпоративными услугами с высокой загрузкой и позволила командам делать выбор технологий на основе измеримых показателей, таких как время холодного запуска и потребление ресурсов.

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

Вы возглавили усилия, чтобы подготовить платформу для международного развертывания, гарантируя, что она хорошо адаптирована для азиатского рынка. На каких технических и продуктах вы сосредоточились? Каковы были ключевые проблемы и результаты?

Платформа ITSM/ESM играет важную роль в оперативном управлении организацией. Это технически сложный продукт B2B, который должен соответствовать строгим нормативным требованиям, особенно при использовании в финансовом или государственном секторах. Адаптация для международных рынков включает в себя гораздо больше, чем просто перевод пользовательского интерфейса. Это требует адаптации к местной инфраструктуре, соблюдение стандартов безопасности, юридическое соответствие, локализацию UX и интеграцию с местными системами. Например, в Китае большинство решений B2B, особенно в регулируемых отраслях, необходимы для хранения данных локально. Если платформа общедоступна, обычно требуется регистрация ICP (поставщик интернет -контента). В правительственных и государственных учреждениях локальное развертывание часто является единственным вариантом из-за строгих требований к контролю данных и соблюдению данных. Кроме того, локальные законы о защите данных (такие как PIPL, APPI и другие) должны строго соблюдать, особенно при обработке конфиденциальной информации и журналов.

Бизнес -логика и рабочие процессы часто должны отражать то, как обстоят дела в разных регионах. Например, в Японии и Южной Корее многие клиенты предприятия и государственного сектора ожидают поддержки иерархических SLA и многоуровневых процессов одобрения, отражающих структурированные методы принятия решений. Локализация платформы является сложной инженерной проблемой, которая требует глубокого понимания региональной специфики и очень гибкой архитектуры.

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

Пройдя от прикладного инженера до архитектора и технического лидера, я работал над сложными, высокоэффективными проектами для мировых компаний, таких как Deutsche Bank. Эти роли подвергали мне строгую инженерную среду, передовые технические практики и дали мне автономию для принятия критических решений, учиться на сбое и развивать глубокое понимание проектирования системы в масштабе.

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