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

Под капотом этой статьи — связь техники, архитектуры и менеджмента, которая приведёт нас к построению объективных показателей надёжности платформенного продукта. Никаких «бумажных SLA» — только прозрачность и настоящие знания.

Привет, Хабр! Меня зовут Игорь Цупко и я — инженерный менеджер с 13+ годами опыта, работаю на стыке технологий, процессов и людей. Создаю устойчивые команды, процессы и платформы для масштабирования бизнеса. В числе кейсов — запуск mos.ru, масштабирование Flant, управление платформами с сотнями приложений в Лемана Тех.

Эта статья написана по мотивам моего доклада для DevOps Conf. Она о том, как SLA связан с финансовыми убытками и как не терять деньги на инцидентах. И у меня в этом есть экспертиза, подтверждённая вполне измеримыми результатами по уменьшению финансовых потерь.

Почему мы теряем деньги

Существует два источника потерь:

1. Плановые изменения — когда в процессе плановых работ что-то вдруг пошло не так. Мы можем бороться с потерями, внедряя процессы change management-а, улучшая инженерную культуру, тестирование и т. п.

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

Но независимо от источника потерь — сосредоточимся на том факте, что инциденты всё равно происходят, что-то ломается — и в итоге бизнес несёт финансовые потери.

Резонно задать вопрос: «Игорь, сам говоришь — мы теряем деньги из-за инцидентов. Причём тут какие-то SLA и девятки на бумаге? Как цифры на экране могут повлиять на реальные потери, которые происходят совсем в другом месте?».

Чтобы разобраться в этом, давайте вместе пройдём путь формулировки SLA надёжности для платформенного продукта.

Терминология. Что такое SLA / SLO / SLI

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

• SLI (Service Level Indicators) — по сути метрики, которые показывают уровень нашего сервиса, насколько качественно мы оказываем услуги.

• SLO (Service Level Objectives) — пороговые значения метрик. Если наши метрики падают ниже значения заданного SLO, мы пытаемся это исправить.

• SLA (Service Level Agreement) — в отличие от двух предыдущих, не имеет непосредственного отношения к мониторингу. Это соглашение, договоренность в явном виде, в виде подписанного юридического документа или просто опубликованного манифеста. В нём мы заявляем, какой у нас уровень обслуживания, условия и так далее.

Наш сервис — low-code платформа для создания и запуска приложений

Разберёмся с сервисом.

В каждой из аббревиатур SLA / SLO / SLI есть буква S, за которой скрывается слово Service.

Речь в этой статье идёт об этакой IDP lowcode платформе. Так как она IDP — она позволяет создавать приложения на основании шаблонов, обеспечивает работу этих приложений и какую-то часть их «инфраструктурной обвязки».

Так как она lowcode — шаблоны, использующиеся для создания приложений, тесно связаны с корпоративным lowcode решением. Бизнес-логика в нём прописана на JSON, а движок его запускает и позволяет работать.

Для того, чтобы формировать JSON, есть визуальная IDE, интегрированная в корпоративные системы.

Таким образом, наши услуги можно сформулировать следующим образом:

• Работа приложения в production. Главная услуга — то, что мы предоставляем платформу для работы приложений. Для пользователей самое важное, чтобы их бизнес-логика работала.

• Работа админки. У платформы есть админка, где пользователи могут управлять правами, посмотреть информацию о приложении, например, всё, связанное с телеметрией (мониторинг, трейсы), настроить алертинг.

• Обработка телеметрии. Работа  инфраструктурной обвязки, которая занимается трейсами, метриками и алертами, хранение этих данных и доступ к ним.

• Деплой CI/CD. Весь необходимый для разработки гигиенический минимум в 2025 году.

• Dev-окружения. Выше мы говорили про работу приложения в продакшн окружении, но разработчикам также нужны dev-, stage- и прочие стенды, на которых можно запускать своё приложение. И платформа избавляет их от того, чтобы думать о разворачивании этих стендов.

• Работа IDE. Так как речь про low code, есть специальная IDE, в которую пользователи заходят править магический JSON хранящий бизнес-логику в удобном визуальном редакторе. IDE позволяет дебажить, расставлять в визуальном режиме блоки логики и делать все необходимые настройки.

• NO OPS. Так как это платформа, разработчики и аналитики могут сосредоточиться исключительно на бизнес-логике. Их не волнует Kubernetes, диски, память и прочая инфраструктура. Весь Platform Operations — в зоне ответственности команды, которая занимается поддержкой и операционным обслуживанием платформы. Разработчики мониторят только свою бизнес-логику. Этот пункт как бы следует из предыдущих, но он настолько важен, что его можно выделить отдельно и три раза подчеркнуть.

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

Отчётность об уровне сервиса

На момент моего прихода, конечно, уже существовала отчётность. Доступность приложений мониторилась путём отправки каждые 5-10 секунд http-запросов на стандартные healthcheck-и, реализованные для Kubernetes (/srv/healthcheck). В результате получалась исчерпывающая информация о доступности разных приложений в разные моменты времени:

Чтобы получить из этого «одно число» — считалась доля успешных проверок: взвешиваем количество «зелёных» результатов по отношению к общему числу проверок. В итоге получалось заветное число с девятками, например, 99,9%.

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

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

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

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

В итоге наша отчётность:

- собиралась в полуручном режиме;

- покрывала не все услуги;

- вызывала боль и ярость.

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

Как не нужно (наверное) строить отчётность

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

Чтобы проиллюстрировать этот тезис — расскажу несколько забавных историй о том, как в разных командах и компаниях строили SLI. Это покажет — как сильно можно пасть, когда отчётность делается для галочки.

Кейс 1. Если алерта не было, падение не считается!

У одной команды был замечательный принцип:

Они брали суммарное время срабатывания всех P1-алертов, вычитали его из общего времени квартала — и получали отличный на первый взгляд показатель качества работы.

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

Кейс 2. Подрядчик сам измеряет качество своих услуг

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

Всё бы ничего, если бы я точно не знал, что эти замечательные люди, при всей своей экспертизе, точно так же «оптимизировали» данные — мухлевали с показателями.

Кейс 3. «Работать будет (пока не сломается), мамой клянусь!»

А вот вам скриншот из одного договора. Возможно, вы даже его видели. В глаза бросается чудесное число 100%. Я тоже хочу такие показатели, просто невероятно!

Просто у них очень классные юристы, которые умеют писать в договоре правильные формулировки — пока не сломается, будет работать, когда сломается, будет как пойдёт.

К чему это здесь? К тому, что как бы ни был плоха ваша реализация SLI/SLO/SLA — вы не одиноки. Возможно, вам приходится долгое время жить по соседству с абсолютным безумием — и это нормально.

Но как бы то ни было, если вы хотите улучшить ситуацию — давайте пройдём этот путь вместе далее.

Начинаем улучшать отчётность

Итак, у нас уже есть какие-то health checks. Логичный следующий шаг — их улучшить, чтобы существующие механизмы начали работать эффективнее.

Я исследовал почему вообще падают мои приложения, что там происходит. И стало очевидно, что проблемы бывают двух видов:

• Часть явно связана с инфраструктурой, то есть это в зоне ответственности моей платформы:

  • Нет доступности по сети.

  • Лёг кластер.

  • и т.п.

• А часть скорее «по душу» разработчиков приложений:

  • Приложение тормозит.

  • Приложение сломано.

  • и т.п.

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

Кейс 1: Блокировки event loop

Приложение на Node.js. У Node.js есть интересная особенность: он вроде бы многопоточный, но на самом деле всегда использует только одно ядро. Переключение между задачами и контекстами идёт быстро-быстро, но если на каком-то кусочке код «залип», то всё — движок в этот момент другие кусочки кода не выполняет.

Event loop способно заблокировать, что угодно: работа с Kafka, RabbitMQ, или взаимодействие по http.

В результате, если Node.js подвисает на одном месте, он может просто перестать отвечать на внешние запросы, например, на health checks. Отличный способ «положить» приложение — заблокировать event loop.

Что с этим делать? Реализуем метрику. Например, можно численно измерять, насколько долго заблокирован event loop. И, допустим, устанавливаем порог: если выше — значит, проблема в приложении, а не в инфраструктуре. 

Результат будет далёк от идеала, но, допустим, позволит как-то отделить баги бизнес-логики от технических сбоев.

Кейс 2: Приложение не запустилось

Может быть, разработчик так «талантливо» написал приложение или накосячил в конфигах, что оно просто не запускается — поехало и не выехало. Понятно, что в таком состоянии оно и на health checks ответить не сможет.

Что с этим сделать? Можно поиграться со startup-пробами — попытаемся настроить дополнительные проверки на этапе старта приложения. Пока startup-проба не прошла (хотя приложение пытается подняться) — не будем учитывать недоступность.

Решение очень сложное, результат сомнительный, но, допустим.

Кейс 3: Упало из-за бага (*) или нет?

А ещё периодически бывает так: приложение выкатили, оно вроде бы работало — а потом упало. Причина — явная ошибка в бизнес-логике. 

И чтобы учесть этот далеко не самые редкий кейс — нужно как-то автоматически понять: проблема внутри (в бизнес-логике или, например, в кривом конфиге) или всё-таки в машинерии вокруг (то есть в платформе).

Что с этим делать? А ничего! Фантазия подсказывает, что должен быть ИИ, который будет быстро анализировать причины падения и решать, стоит ли учитывать этот инцидент в платформенной отчетности или можно его вычесть.

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

Промежуточные выводы

Все три кейса — и с event loop, и со стартап-пробами, и с распознаванием бизнес-ошибок — очень долго и дорого реализовывать. А результат — практически никакой.

И это — разбор только заветной «Работы приложения в production». А какие драконы нас ждут, если мы полезем в остальные услуги?

На этом этапе своего жизненного пути, я, признаюсь, отчаялся:

• Сделать хорошие метрики — не получилось.

• Отразить ожидаемые клиентами услуги — не получилось.

• Бумажный SLA безоговорочно победил.

Окей. Давайте лучше займемся чем-нибудь другим. Полезным.

Как уменьшить потери, не сделав SLA для клиентов

Несмотря ни на что, работа SRE продолжается.

Что-то ломается, где-то — очевидно — хочется что-то улучшить.

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

Как SLI (вдруг!) помог разгрести вал задач

Конечно, хорошие SRE не сидят без дела. И, когда у них уже есть задачи, прибегает очередной клиент: «Ребята, спасите, теряю трейсы! Срочно что-то делайте!». Как быть?

В один из таких моментов мне очень повезло: я наткнулся на отличную книгу, которая сильно повлияла на мой подход — The Site Reliability Workbook. Рекомендую от души.

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

Мне же, кроме прочего, пригодилась классификация метрик в зависимости от их типа:

• Request-driven метрики — для всего, например, что отвечает на http-запросы:

  • Availability;

  • Latency;

  • Quality.

• Pipeline — для данных, которые летят куда-то из одного места в другое:

  • Freshness;

  • Correctness;

  • Coverage.

• Storage — для хранилищ:

  • Durability.

И пригодилась она тем, что мои услуги концептуально очень хорошо легли на эти классы!

Возвращаясь к товарищу с пропавшими трейсами — раз у него теряются метрики — значит их надо рассматривать как Pipeline. «А много ли данных потерялось, пока шло по трубе до хранилища?» — задаю я вопрос. Потому что у трубы есть простой показатель: сколько данных добралось до конца без потерь. Выясняется: потеря — 2 трейса из 1000. То есть наша метрика качества доставки — 99,9998%. Отличный результат.

Это значит, что если кто-то хочет 100% SLI на доставку трейсов до хранилища — это красивая мечта, но в реальности она будет стоить космически дорого. А я, в свою очередь, не могу тратить силы команды на микроскопические потери, когда рядом есть задачи с реальным импактом.

Если распыляться на всё подряд, вместо фокусировки на критичных местах — накапливается SRE-долг, который постепенно конвертируется в долг финансовый.

Так, сформулировав чисто технические SLI стало легче приоритезировать поступающие запросы. И, что очень важно — формулировка SLI помогла только при условии налаженной SRE-работы именно в фокусировке усилий в правильном направлении.

Как (вдруг!) оказалось, что существует инфраструктура

Иронично, что разработчики часто упускают факт существования инфраструктуры под своим приложением. Точно также и моя платформа не существует в вакууме. Она работает поверх инфраструктурных слоёв — Kubernetes, виртуализация, железо и так далее.

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

Можно было бы задать вопрос так:

— Инфра, где ваши SLI?

— Их нет.

Обратите внимание: я здесь спрашиваю не про SLA, а именно про SLI.

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

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

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

В моём случае — на накопленном опыте — захотелось видеть что-то про:

• Потери данных (например, выход из строя PVC).

• Выбивание подов с нод.

• Выходы из строя нездоровых нод.

• Оверселлинг процессоров.

• Запас памяти.

• Запас дисков.

• Возможность масштабировать CPU.

• Качество связи с базами и внешними ресурсами.

• Быстродействие дисков.

• Сетевые потери.

• Запас трафика на сетевых картах.

И этот список хорошо иллюстрирует то, как платформа стыкуется с нижележащей инфраструктурой.

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

Чему учат нас SLI инфраструктурных сервисов

Когда мои клиенты приходили ко мне (платформе) и просили SLA — они хотели, чтобы я им сказал что-то про доступность и latency их приложений. Исходя из этой мысли и была построена отчётность с healthcheck-ами на /srv/healthcheck — та самая, которую так и не получилось внятно реализовать.

Они спрашивали это, потому что хотели сделать логичную арифметическую операцию:

Следуя этой логике, мне нужно было бы запросить SLA на доступность у инфры. Но в выше описанных метриках у инфры нет ничего про SLI доступности. И это абсолютно нормально. Потому что проблема индейцев — не проблема шерифа. Latency и доступность приложений — это зона ответственности продуктов, а не платформы.

Каждый продукт — как мясорубка: в него поступают данные из внешних API, Kafka, Rabbit-а, очередей, баз данных, а ещё сверху сыпятся CPU, RAM и диски, а на выходе продукт производит свой API. И то, как хорошо продукт справляется с превращением чего бы то ни было в свой сервис — его и только его зона ответственности.

Платформа — это тот же инфраструктурный слой, который предоставляет что-то, но не обязательно http API. И не должны её услуги хоть сколько-нибудь покрываться теми же метриками, что http API.

Формулируем новые SLA надёжности платформы

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

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

Особо продвинутые слышали о существовании k8s, openstack/vmware. Некоторые даже подозревают, что под облаками всё-таки есть железо (но это не точно). Но мы-то знаем реальную картину: под капотом у нас kubernetes-поды, настройки масштабирования, потребления ресурсов и множество других параметров, влияющих на работу приложения (и оказываемые услуги).

Когда мы говорим о работе приложений — той самой, которую раньше пытались мерить с помощью health checks, — на самом деле мы должны были смотреть на:

• Ресурсы для выполнения кода — мы предоставляем CPU для выполнения бизнес-логики и RAM для её работы.

• Возможность масштабирования — если приложению потребуется масштабирование, мы должны обеспечить ему возможность развернуться. Если, например, в Kubernetes приложение запрашивает 8 реплик, а получить может только 4 — это проблема нашей платформы и её SLA.

• Запуск cron-заданий — если в приложении настроены задачи по расписанию, и мы не обеспечили их своевременный запуск, это тоже наша проблема.

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

Архитектура и технологии как основа платформенных услуг

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

Проиллюстрирую это на примере обработки телеметрии. Работа с телеметрией состоит из трёх этапов:

• Телеметрия обрабатывается (процессится).

• Данные хранятся стабильно и надёжно.

• По запросу пользователя данные отображаются в интерфейсе.

Если брать первую часть — то с технической точки зрения данные проходят по протоколу OpenTelemetry: из агентов в коллекторы, и дальше в систему хранения. Причём, что характерно, OpenTelemetry сам умеет отдавать инфраструктурные метрики, которые нас так волнуют — например, сколько данных он дропнул. То есть, буквально, есть способ получить SLI из коробки, если понимать архитектуру.

Архитектура и system design тесно связаны с набором наших платформенных услуг. Когда система проектируется или развивается эволюционно, по архитектуре можно понять, какие именно услуги реально предоставляются. И при построении SLA важно учитывать это знание: какие именно компоненты и технологии лежат в основе работы сервисов.

Пишем SLA

SLA — это Service Level Agreement, соглашение об уровне сервиса. Но чтобы о чём-то договариваться, надо точно понимать, про что именно идёт речь с чем, как мы говорили выше, есть проблемы.

Например, одна из моих любимых тем — телеметрия. Я бы с радостью дал какие-то гарантии на её обработку. Но, как водится, есть нюансы.

1. Отказоустойчивости — нет

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

2. В production у моих клиентов — legacy решения, снятые с поддержки

Часть клиентов до сих пор сидит на старой версии телеметрии, которая уже снята с поддержки. Это чистое legacy. Но съезжать с неё они не хотят — просто так исторически сложилось. 

3. Существуют альтернативные инструменты

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

И, что характерно, всё это — крайне важно для понимания сервиса, но всё это — не про «девятки».

Это просто информация — понимание, которое можно оформить в документ, донести до людей, обучить, поговорить с ними. Главное — чтобы у них в голове появилось чёткое понимание, на что можно реально опираться как на бизнес-критичную функцию, а на что нет, куда даже не стоит идти.

Например, не надо пытаться скрейпить данные мониторинга из GUI для своего бизнес-критичного приложения. Всё равно упадёт — и мы на это никаких гарантий не даём.

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

Формулировка заветных «девяток» и построение отчёности с числами

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

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

Вместо заключения или TLDR

Если вы прочитали весь текст до этого места — мой вам низкий поклон :) Постучитесь ко мне в личку, я с радостью подушню вместе с вами на тему надёжности, кажется, нам есть о чём поговорить.

Для тех же, кто пролистнул сюда сразу — маленький TLDR, ключевые тезисы:

• Нет, SLA никак не помогает сократить потери само по себе.

• Сократить потери помогает квалифицированная работа SRE: постмортемы, решение инцидентов и расследование проблем, эволюционное улучшение системы, change management.

• Но SLI помогают сосредоточить SRE на действительно важных вещах, позволяя отбросить несущественное. И это позволяет «нагнать» копящийся инфраструктурный техдолг и снизить потери.

• SLI платформы НЕ РАВНО SLI продукта — тут я прошу вас всё же пролистнуть наверх к главе «Чему учат нас SLI инфраструктурных сервисов» и прочитать её :) Там важное про то, что такое услуги платформы, и в чём вообще отличие продукта и платформы.

• Культура совместной работы и отсутствия искусственно возведённых стен «отчитайтесь за себя» критически полезна, без неё, боюсь, ничего не получится. Потому что платформенные продукты — на самом деле про инфраструктуру. Она сложная, запутанная, и важно вникать в неё целиком, без границ и препонов.

Приходите слушать доклады Игоря Цупко на следующую DevOps Conf — смотрите на сайте конференции темы докладов и подробную программу.