Большинство современных компаний имеют обширную территорию, состоящую из международных команд и огромных мультиоблачных архитектур, объединенных Kubernetes, конвейерами CI/CD, инфраструктурой как кодом (IaC) и многими другими взаимосвязанными инструментами.
Эта запутанная среда облегчила командам быструю работу и глобальное развертывание, но делает реагирование на инциденты огромной головной болью для инженеров по надежности объектов (SRE).
Роксана Фишер, генеральный директор и соучредитель Anyshift, осознала эту реальность, когда она и Стефан Журдан, соучредитель и технический директор, решили запустить Anyshift: «С первого дня существования компании мы всегда понимали, что одна из самых больших проблем в этой области сейчас заключается в том, что в вашей инфраструктуре есть разные разрозненные блоки… которые не реагируют друг на друга, когда у вас возникают проблемы, особенно в производстве для ваших инженеров».
Она не одинока в этом наблюдении. И похоже, что все эти разрозненности могут влиять на время реагирования на инциденты. В ходе опроса 1000 специалистов по ИТ-операциям, DevOps, SRE и разработке платформ, проведенного в 2023 году, 62% заявили, что за последний год они заметили увеличение времени, необходимого для разрешения инцидентов.
Что их тормозит? Фишер говорит, что причиной хаоса и отсутствия контекста является управление фрагментированной, разросшейся инфраструктурой.
Слишком много инструментов, недостаточно контекста
Многие организации совмещают AWS, GCP и Azure, а также кластеры Kubernetes, конвейеры CI/CD, инструменты IaC и многое другое. Хотя проектирование мультиоблачной или гибридной инфраструктуры имеет очевидные преимущества с точки зрения гибкости, скорости и избыточности, это также означает, что нужно многое отсеять, когда придет время реагирования на инциденты и анализа первопричин.
Как говорит Фишер: «Когда у клиента возникает проблема с задержкой, очень сложно узнать, [if] это происходит из-за смешанной конфигурации в вашем кластере Kubernetes или… изменения, которое создало эффект снежного кома».
Даже всего одно предупреждение могло быть вызвано дюжиной различных факторов, создавая головокружительные кроличьи норы для поисков SRE — особенно хаотичная задача при работе под принуждением в метко названном «военном помещении».
Фишер называет этот анализ первопричин одной из самых больших болевых точек в отрасли. А используемые ныне инструменты, по ее словам, не обеспечивают адекватной поддержки: «Традиционные инструменты мониторинга скажут вам, что изменилось, но не расскажут, почему. Они не дадут вам контекста проблемы».
Anyshift стремится обеспечить этот контекст.
Знакомьтесь, Энни: кратчайший путь SRE через кроличью нору
Контекст берется из постоянно обновляемого графа инфраструктуры и умного помощника по имени Энни.
Anyshift принимает и структурирует данные из нескольких источников для создания живой карты инфраструктуры и производства компании, создавая единый источник достоверных данных, отображающий взаимосвязи между сервисами, облачными ресурсами, конфигурациями и кодом.
Когда случается инцидент, все, что нужно сделать командам SRE, — это отметить Энни, которая затем приступит к расследованию проблемы. Она использует оповещение в качестве точки входа, следует по пути зависимости от внешнего интерфейса к внутреннему и запрашивает оперативные журналы и показатели из интегрированных инструментов, таких как Datadog или Grafana.
«Она будет вести себя так же, как… SRE», — заявляет Фишер. «Она пройдет разные пути расследования, спросит, что ей нужно, и в конце создаст [root cause analysis] сообщить по каналу инцидента».
Примечательно, что Энни не просто представляет свои выводы; она тоже показывает свою работу.
«[She] тогда объясни[s]Это примечательный шаг за пределами возможностей многих инструментов AIOps или AI SRE, которые обычно собирают большие объемы данных для выявления потенциальных первопричин без объяснения причин.
Эксперты могут приходить и уходить, но помощник никогда не выходит из системы
Реагированию на инциденты препятствуют не только недостатки традиционных инструментов мониторинга. Институциональная природа многих команд SRE также создает пространство для рисков.
Некоторые инциденты легко исправить, если вы работаете с опытными SRE, которые были там, делали это и знают, как отследить проблему, не отнимая много времени.
Но если вашей команде не хватает такого практического опыта, то даже рутинные расследования могут внезапно стать намного более трудоемкими. «Это все равно, что найти иголку в стоге сена», — говорит Фишер. «Как мне пройти эти разные пути исследования и попытаться понять, почему возникла эта проблема?»
Опытные SRE часто первыми получают пинг, когда что-то идет не так. Но хотя их многолетний опыт может показаться преимуществом, на самом деле это недостаток, который может очень быстро обернуться катастрофой.
«Если эти люди уйдут, это будет катастрофа», — предупреждает Фишер. «Если их здесь нет, младшие сотрудники очень часто теряются, потому что не получают информации».
Больше контекста = более быстрые исправления + меньше труда
Влияние затянувшегося реагирования на инциденты выходит за рамки пустой траты времени, хотя это и является существенным недостатком. Согласно одной из книг Google SRE: «Ежеквартальные опросы SRE Google показывают, что среднее время, затрачиваемое на труд, составляет около 33%», при этом некоторые исследователи утверждают, что трудится 80% времени.
Стоимость, конечно, является еще одним тревожным побочным эффектом. Согласно опросу PagerDuty, решение среднего инцидента занимает 175 минут и обходится почти в 794 000 долларов.
Помимо потерянных минут и денег, длительное реагирование на инциденты вредит компаниям, отвлекая SRE от более ценной работы. Это особенно беспокоит Фишера, который говорит, что одна из основных задач Anyshift — вернуть то время назад:
«Как мы на самом деле можем помочь этим SRE, [so they’re] не исправлять инциденты, которые [were] вызванные прошлыми модификациями, но высвободите немного времени для дежурных инженеров, чтобы они могли сосредоточиться на задачах… [that] на самом деле улучшить и создать[e] что-нибудь для компании?
Создание карты контекстно-ориентированного будущего
Сейчас Anyshift сосредоточена на сценариях дежурства — то, что Фишер называет первым «пожаром», который нужно потушить. Но в дальнейшем она рассматривает граф инфраструктуры стартапа как основу для следующей итерации AI SRE, которая не просто реагирует на инциденты, но помогает командам постоянно улучшать и оптимизировать инфраструктуру с точки зрения затрат, задержек и надежности.
Для этого потребуется добавить больше контекста путем наложения данных приложения на граф инфраструктуры для отображения всей производственной системы. Только тогда Фишер считает, что Anyshift сможет достичь своей конечной цели — «ликвидировать разрыв между разработчиком и командой DevOps, между инфраструктурой и миром приложений».
Такая сквозная прозрачность должна не только улучшить реагирование на инциденты; оно также должно устранить необходимость указывать пальцем, которая часто возникает при реагировании на инциденты между командами.
Для Фишера все сводится к одному вопросу: «Как на самом деле улучшить всю систему?»
Их еще нет, но если будущее AI SRE зависит от контекста, то Anyshift, безусловно, строит «карту» для достижения этой цели.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Мередит Шубель — технический писатель, освещающий облачную инфраструктуру и корпоративное программное обеспечение. С 2022 года она сотрудничает с The New Stack, рассказывая о стартапах и изучая, как организации внедряют новые технологии. Помимо The New Stack, она пишет официальные документы, подписи руководителей и т. д. Подробнее от Мередит Шубель
