AI берет инциденты на себя — инженеры теряют связь с системами

У автора голова на плечах, но мало кто из компаний вообще будет тратить время на симуляции инцидентов для своих SRE.

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

Пилоты авиакомпаний проходят тренировки по аварийным ситуациям, потому что это требуется по закону. Если бы это не было условием получения лицензии пилота, ни одна компания за это не платила бы.

Хотите, чтобы SRE тратили время на тренировки к авариям? Шаг назад. Поддержите профессиональную сертификацию. Сделайте это условием получения лицензии. Вы не получите профессионального поведения в отрасли, пока не профессионализируете работу. Без лицензирования этого не будет, потому что каждый срезанный угол, который не виден потребителям, означает дополнительную прибыль, а растущая конкуренция в итоге требует срезать эти углы, чтобы не отставать и оставаться в бизнесе. Принуждение всех игроков к лицензированию заставляет всех нести эти расходы и тем самым запрещает им [...]

Я нахожу использование ИИ похожим на зыбучий песок.

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

Ревью кода важно, но оно не заменяет ментальную модель, которую я могу построить, когда делаю все шаги разработки вручную без ИИ.

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

К счастью, есть способы смягчить это и по сути перевести человеческую интуицию о том, каким код должен быть, в ограничения для агентов. Но без этого вы плывёте по стохастическому морю, где каждая волна не похожа на предыдущую.

Я замечаю, что время от времени всплывают аналогии с авиацией. В авиации отказ катастрофичен, и системы, которыми вы управляете, не меняются на лету (каламбур).

Возможно, вы можете натренировать SRE таким образом, но вы учите их только эффективно _реагировать_, а не _исправлять_ уникальные единорожьи первопричины этих отказов. Аналогия с авиацией была бы инженером самолёта, который пытается тренироваться одновременно на отказы двигателя в полёте, отладку двигателя и его редизайн.

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

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

Сравнение с пилотами немного неуместно, потому что область применения сильно варьируется для каждой компании и продукта. Придумывать синтетические симуляции в каждой области — это платить дважды за одно и то же; почему бы не позволить инженерам изначально разбираться с реальными инцидентами? Более того, почему бы не потратить больше усилий на создание лучших систем.

Код тоже.

Я работаю с программистами, и не редкость, что они с поразительной точностью помнят код, который писали в прошлом.

Кто-то может упомянуть проблему, которая возникла, и они задумаются на мгновение и действительно вспомнят, откуда эта проблема в коде, потому что помнят, как писали это около 8 месяцев назад.

Этот навык будет потерян, когда ИИ будет генерировать весь код; мы застрянем в бесконечном цикле, где ИИ отслеживает состояние кода, чтобы ИИ мог его расширять и поддерживать.

Я видел вариант этого, когда случайных инженеров привлекают к звонкам по инцидентам в проде, и от инженеров не ожидается, что они знакомы с системой.

Им говорили "просто используй ИИ", чтобы понять компонент, провести триаж, собрать фикс и т.д. Инженер был вынужден выбирать между принятием потенциально посредственного фикса, предложенного ИИ, или риском показаться некомпетентным ресурсом, который не умеет использовать ИИ.

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

Если рост возможностей продолжится такими темпами, то инцидент, который не может разрешить ИИ, поставит в тупик и людей, независимо от практики.

Мне нравится пример с самолётами из статьи, но думаю, в реальности будет как с кодом. 1,5 года назад инженеры часто говорили, что иногда пишут код вручную, чтобы поддерживать навыки, и теперь такое услышишь редко, если вообще услышишь.

Если SRE столкнётся с ситуацией, которую ИИ не может решить, то этот SRE будет использовать ИИ-системы для дальнейшего триажа, указывать им на другие места и так далее.

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

Есть лишь ограниченная потребность во вкусе и суждениях, прежде чем даже это будет включено в модели.

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

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