Автор, сотрудничающий с изданием
Что корпоративные команды DevOps должны усвоить у SaaS
анализ
7 апр. 2026 9 мин
Как корпоративные команды DevOps могут повысить отказоустойчивость своих критически важных приложений, интеграций и конвейеров данных? Обратите внимание на практики провайдеров SaaS.
Источник: fran_kie / Shutterstock
Многие корпоративные команды DevOps испытывают трудности с частыми релизами, увеличением автоматизации тестирования и обеспечением надежных выпусков. Чему они могут научиться у компаний SaaS, для которых разработка и развертывание ПО для тысяч клиентов — основа выручки и бизнес-операций?
Компании SaaS должны иметь надежные возможности тестирования, наблюдаемости, развертывания и мониторинга. Одно неудачное развертывание может нарушить работу клиентов, сорвать возможности продаж и привлечь негативное внимание СМИ.
Особенно сложно то, что многие платформы SaaS настраиваемы и обладают возможностями low-code-разработки. Таким платформам нужны надежные наборы тестовых данных и мониторинг в реальном времени, чтобы убедиться, что развертывания не ломают функциональность для клиентов. Сбой даже у небольшой доли клиентов — недопустимый результат.
Проверка форм ввода данных и сквозных рабочих процессов — это комбинаторная задача, требующая создания надежных наборов данных и проверки статистической значимости шаблонов ввода. Кроме того, разработка, интеграция и развертывание ИИ-агентов и языковых моделей добавляют новые сложности. В корпоративной среде тестирование открытых ИИ-агентов с недетерминированными ответами становится еще более сложной задачей по мере того, как все больше организаций используют сторонних ИИ-агентов и переводят ИИ-эксперименты в промышленную эксплуатацию.
Я попросил поставщиков SaaS поделиться некоторыми секретами их DevOps. По мере того как все больше корпоративных команд DevOps разрабатывают, внедряют и поддерживают критически важные приложения, интеграции и конвейеры данных, как они могут повысить отказоустойчивость? Обратите внимание на практики провайдеров SaaS.
Стремитесь к умным «обновлениям для клиентов»
Если вы выпускаете обновление, воспользуются ли конечные пользователи новыми возможностями или будут раздражены дефектами, попавшими в production? Предприятия должны стремиться к умным обновлениям для клиентов, которые бесшовны для конечных пользователей, выпускаются часто, имеют низкий уровень дефектов, избегают проблем безопасности и стимулируют внедрение новых возможностей.
Чтобы последовательно достигать этих целей, корпоративным командам DevOps нужно принять изменение мышления, уйдя от устаревших ИТ-норм. Им следует признать, что:
- Конечные пользователи — это клиенты, и нарушение рабочих процессов влияет на бизнес-операции. Повышение частоты развертывания при выпуске с дефектами — не победа ни для SaaS, ни для корпоративного ИТ.
- Развертывание возможностей, которые мало кто замечает, пробует и внедряет, — серьезная проблема. Это означает, что команда потратила время и ресурсы, не создав бизнес-ценности и, вероятно, добавив новую техническую задолженность.
- Развертывание ПО никогда не бывает разовой задачей, и agile-команды должны сообщать свои планы управления релизами.
«Самые успешные команды DevOps понимают, что их внутренняя платформа на самом деле является специализированным SaaS-продуктом, где разработчики — основные клиенты», — говорит Серхио Родригес Инклан, старший инженер DevOps в Jalasoft. «Заменяя жесткие сроки проектов обязательством обеспечивать непрерывную надежность и автоматизацию самообслуживания, ИТ перестает быть корпоративным узким местом и становится конкурентным преимуществом».
Одно из преобразований, которое сейчас проводят многие предприятия, — переход к ИТ, ориентированному на продукты, что помогает группировать приложения в продукты и назначать менеджеров продукта для контроля их дорожных карт. Большинство компаний SaaS назначают менеджеров продукта, чтобы доносить видение продукта, определять пользовательские персоны, понимать потребности клиентов, приоритизировать функции и измерять бизнес-результаты.
Эско Ханнула, старший вице-президент по робототехнике в Copado, говорит: «Современный корпоративный ИТ должен принять мышление SaaS. ПО — это не проект с конечной датой, а постоянно улучшаемый продукт, поставляемый через частые инкрементальные релизы».
Ханнула рекомендует изучить практики DevOps, используемые командами SaaS, включая продвинутый CI/CD, непрерывное тестирование, канареечные релизы, A/B-тестирование и управление продуктом на основе данных, чтобы иметь возможность выпускать обновления когда угодно. «Эти практики важны, потому что они создают уверенность, гибкость и качество, необходимые для быстрого реагирования на изменения бизнеса — результаты, которые естественным образом возникают, когда ПО рассматривают как долгоживущий продукт, а не разовый проект», — говорит Ханнула.
Пишите меньше кода и тестируйте больше
Разработчики в корпоративном ИТ используют ИИ-генераторы кода и экспериментируют с инструментами vibe coding. Исследования показывают, что эти инструменты могут повысить производительность разработчиков на 30% и более. Но приведет ли рост производительности к тому, что команды DevOps будут выпускать функции быстрее и надежнее?
У корпоративного ИТ долгая история недофинансирования тестирования и ориентации на крупные «big-bang» развертывания. Компании SaaS делают наоборот. Они применяют аналитику в автоматизации тестирования, создают синтетические наборы тестовых данных и используют feature flags, чтобы снизить риски более частых развертываний. Более продвинутые компании SaaS внедряют непрерывное развертывание, но для многих предприятий это может быть трудно реализовать.
«Автоматизация тестирования может казаться первоначальными затратами, но она быстро окупается, потому что более устойчивые сервисы приводят к меньшему числу инцидентов, меньшему числу обращений в поддержку и снижению операционных издержек», — говорит Нихил Мунгел, директор по ИИ R&D в Cribl. «Команды SaaS часто снижают риски запусков, сначала выкатывая функции небольшим группам и используя наблюдаемость, чтобы отслеживать состояние системы и пользовательский опыт до широкого релиза, обычно через feature flags и bucketing. Команды ИТ DevOps могут повторить это, позволяя “power users” подключаться раньше, повышая удовлетворенность и снижая нагрузку на поддержку».
Безопасность в проектировании, разработке и развертывании
Повышение производительности, которое дают генераторы кода, может иметь свою цену. В том же упомянутом выше исследовании, показавшем рост производительности разработчиков и поддерживаемости кода, также было обнаружено, что в сгенерированный код было внесено на 23,7% больше уязвимостей безопасности.
Сдвиг безопасности влево звучит просто, но на деле это широкая повестка для корпоративных команд DevOps, которые хотят, чтобы безопасность стояла наравне с приоритетами разработки и эксплуатации. Чтобы стать DevSecOps, agile-команды должны заниматься безопасностью и соответствием требованиям не только на уровне безопасности приложений, но и включая укрепление облачной инфраструктуры, управление идентификацией, безопасность данных и смещение ИИ-моделей.
«Команды SaaS выигрывают, когда встраивают безопасность в свою кодовую базу с зависимостями, которые обновляются бесшовно», — говорит Дэвид Миттон, CEO Arcjet. Миттон рекомендует эти четыре практики:
- Наборы тестов с автоматическими проверками безопасности и конфиденциальности, которые сигнализируют о поломке зависимостей.
- Стандартизированная наблюдаемость со структурированными трассировками и богатыми контекстом логами.
- Управление данными с учетом конфиденциальности и маскирование PII в приложении с CI/CD-ограничениями.
- Feature flags и канареечные выкладки, чтобы двигаться быстро, не ломая клиентов и соответствие требованиям.
Прия Савант, GM и вице-президент по платформе и инфраструктуре в ASAPP, добавляет, что современные команды SaaS сдвигают безопасность влево, встраивая безопасность, тестирование, контроль доступа и наблюдаемость в проектирование и CI/CD-конвейеры, а не добавляя их в конце. «Автоматизация разрешений, внедрение “золотых” пайплайнов и встроенной наблюдаемости устраняет трение, повышает качество и ускоряет поставку. Команды ИТ и DevOps, которые принимают эту модель, двигаются быстрее и масштабируются надежнее, чем те, кто застрял в ручных согласованиях и реактивных рабочих процессах», — говорит Савант.
Начинайте планировать отказоустойчивые операции с Day 0
Когда я был CIO, меня однажды спросили, какова наша модель Day 2 для нового приложения, которое мы разрабатывали. Day 2 — это устаревший термин для момента, когда приложение развернуто в production и требует поддержки, в отличие от Day 1 (разработка) и Day 0 (планирование).
У команд SaaS совершенно иное отношение к эксплуатации, и они начинают планировать масштабируемость, безопасность, производительность и управление инцидентами с самого начала при проектировании архитектуры.
Например, компании SaaS уделяют большое внимание опыту разработчиков. Разработчики, которые слишком заняты настройкой облачных конфигураций, ручным исправлением компонентов или обработкой задач управления данными, могут потерять фокус на потребностях клиентов.
«Инженеры SaaS используют технологии, которые не усложняют вещи сверх меры и позволяют им быстро двигаться, не борясь с путями обновления», — говорит Алехандро Дуартe, инженер по отношениям с разработчиками в MariaDB.
Дуартe рекомендует выбирать инфраструктуру, которая не тормозит разработчиков. Например, на уровне данных он отдает приоритет системам, поддерживающим нативную репликацию, векторное хранение, быструю аналитику и автоматическое восстановление узлов.
Определите стратегию наблюдаемости, а затем внедрите ее
Еще один сдвиг мышления, вдохновленный SaaS, — переход от мониторинга приложений как «черных ящиков» на Day 2 к наблюдаемости на Day 0, предоставляющей операционным командам детали, необходимые для управления инцидентами и анализа первопричин. В корпоративной среде установление стандартов наблюдаемости крайне важно, поскольку операционные команды отслеживают оповещения и инциденты в сотнях и тысячах приложений.
«Команды ИТ DevOps могут научиться у разработчиков SaaS тому, что наблюдаемость — это не просто мониторинг систем после развертывания, а встраивание реального контекста на каждом этапе разработки», — говорит Ноам Леви, основатель-инженер и field CTO в groundcover. «Современные инструменты наблюдаемости, особенно в сочетании с ИИ, помогают инженерам предсказывать регрессии до того, как они произойдут в production-среде, направляя более безопасные изменения кода и более надежные релизы. Этот переход от реактивного устранения неполадок к проактивной надежности отражает то, как ведущие команды SaaS постоянно совершенствуют и укрепляют доверие к своему ПО».
Важность наблюдаемости была общей темой среди лидеров SaaS, и многие считают ее обязательным условием DevOps. Но логирование каждой крупицы информации может стать дорогим и сложным, особенно когда ИИ-агенты фиксируют все взаимодействия.
«По мере того как системы на базе ИИ генерируют экспоненциально больше логов, метрик и трассировок, тесно связанные стеки наблюдаемости не могут держать достаточный объем данных в горячем хранении без роста затрат или выгрузки их в медленное cold storage, по которому трудно выполнять запросы», — говорит Эрик Тчеттер, главный архитектор в Imply. «Если использовать хранилище наблюдаемости как масштабируемый слой данных, команды сохраняют доступность телеметрических данных в масштабе без увеличения затрат».
Энг Ли, директор по инженерии в Observe, делится хорошим правилом, которое команды SaaS используют, чтобы решать, какую информацию включать в свои стандарты. «Инженерные команды SaaS проектируют наблюдаемость вокруг пользователей и рабочих процессов, а не только вокруг того, работают системы или нет. ИТ DevOps может применять тот же подход, выходя за рамки мониторинга времени безотказной работы и инструментизуя критические бизнес-транзакции, чтобы лучше понимать влияние на пользователей, ограничивать радиус поражения и быстрее восстанавливаться», — говорит Ли.
Ключевые выводы
Из рекомендаций наших экспертов выше можно выделить два ключевых вывода для корпоративных команд DevOps. Во-первых, применяйте практики управления продуктом, фокусируйтесь на важных функциях и развивайте надежное тестирование. Во-вторых, сдвигайте влево не только практики, но и культуру, рассматривая наблюдаемость, безопасность и отказоустойчивость как часть архитектуры решения.
DevopsРазработка ПОSaaSОблачные вычисленияКарьера
Автор, сотрудничающий с изданием
Исаак Сэколик, президент StarCIO, компании по обучению цифровой трансформации, помогает руководителям внедрять практики, необходимые для управления преобразующими изменениями в их организациях. Он является автором Digital Trailblazer и бестселлера Amazon Driving Digital и выступает на темы agile-планирования, DevOps, data science, управления продуктом и других лучших практик цифровой трансформации. Сэколик — признанный топ-руководитель CIO в соцсетях, влиятельный эксперт по цифровой трансформации, и у него опубликовано более 900 статей на InfoWorld, CIO.com, в его блоге Social, Agile, and Transformation и на других сайтах.
Мнения Исаака принадлежат только ему.
Еще от этого автора
Показать еще
новости
Z.ai представляет GLM-5.1, позволяя ИИ-агентам для кодинга автономно работать часами
Автор: Prasanth Aby Thomas8 апр. 20264 мин
Искусственный интеллектИнструменты разработкиОткрытый исходный код
новости
Новый Agent Governance Toolkit от Microsoft нацелен на основные риски OWASP для ИИ-агентов
Автор: Anirban Ghoshal8 апр. 20263 мин
Искусственный интеллектИнструменты разработкиБезопасность
материал
Начните работу с новым типом frozendict в Python
Автор: Serdar Yegulalp8 апр. 20265 мин
Языки программированияPythonРазработка ПО
видео
Новый тип frozendict в Python
видео
Как повысить производительность приложения с помощью ленивого импорта Python 3.15
видео
Как запустить свой собственный маленький локальный Claude Code (ну, почти!)
26 мар. 20267 мин
Python
Материал — перевод статьи с английского.
Оригинал: What enterprise devops teams should learn from SaaS