План на 2020: облако, GitOps на все кластеры и error budget в SLA

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

Итоговый пост по 2019-му мы опубликовали несколько дней назад. Там - что получилось. Здесь - что делаем дальше.

Первое - завершить миграцию на CentOS 8

CentOS 8 вышел в сентябре, и с тех пор мы провели несколько развёртываний - как собственных тестовых стендов, так и у клиентов. Общая картина: DNF быстрее YUM, AppStream-модульность решает часть проблем с версионированием пакетов, SELinux-политики в целом совместимы с тем, что было на семёрке, если не тащить экзотику.

Но это не «просто обновить». CentOS 8 - другая система в части управления пакетами, и наши Ansible-роли, написанные под CentOS 7, местами нужно переписывать, а не адаптировать. Модульность AppStream - это концепция, а не просто флаг в dnf, и если не понимать, как работают streams и profiles, получишь неочевидные конфликты при обновлении.

В 2020-м хотим закрыть три вещи:

• Перевести все собственные продакшн-серверы на CentOS 8 до середины года. Остаток на семёрке - только там, где есть жёсткая зависимость от конкретного пакета без аналога.
• Переписать ключевые Ansible-роли под CentOS 8 как базовый дистрибутив. Не «добавить ветку для 8», а сделать восьмёрку основной - с откатом для семёрки где нужно.
• Провести пилот миграции у двух клиентов: один с типовой LAMP-историей, другой - с Kubernetes-кластером. Разный профиль зависимостей, разные риски - нужны оба кейса.

Осторожность нужна: CentOS 8 только вышел, и некоторые пакеты из EPEL ещё не перенесли. Прежде чем катить на клиентские системы, будем проверять вручную.

Второе - GitOps на все production-кластеры

В 2019-м мы запустили GitOps через Argo CD у нескольких клиентов - опыт описали отдельно. Там, где внедрили, результат ощутим: состояние кластера живёт в репозитории, откаты через git revert, история изменений без разговоров «а кто менял replica count в пятницу».

Проблема в том, что coverage неполный. Есть кластеры, где часть ресурсов всё ещё управляется руками через kubectl, часть - через ad hoc-скрипты. Это не злой умысел - просто так сложилось: где-то GitOps внедряли на новые проекты, а старые трогать не было времени.

На 2020-й задача конкретная: ни одного продакшн-кластера без GitOps-пайплайна к концу года. Что это значит на практике:

• Аудит текущих кластеров - что живёт в Git, что нет, где есть дрейф между репозиторием и реальным состоянием. Argo CD умеет показывать drift, и картина там местами неприятная.
• Унификация структуры репозиториев - сейчас у нас несколько схем, каждую придумывал другой инженер в другое время. Нужен один стандарт, который все понимают одинаково.
• Работа с клиентскими командами - там, где разработчики деплоят сами, нужно объяснять новый процесс. Это не технический вопрос, это организационный. И он сложнее.

Отдельная тема - multi-cluster: у нескольких клиентов уже больше одного кластера, и управлять ими из единой точки мы хотим через app-of-apps паттерн в Argo CD или федеративный подход. Это новая территория, и наскоком туда идти не стоит.

Третье - error budget в договорные SLA

Это самое амбициозное из трёх. И, вероятно, самое сложное не технически, а переговорно.

Летом мы внедрили error budget у ретейл-клиента во внутреннем формате - как инструмент наблюдения и аргументации. Сработало хорошо: данные о расходе бюджета стали общим языком между инженерами и бизнесом. Следующий логичный шаг - перенести это в договорные отношения.

Что имеем сейчас: классические SLA с uptime в процентах и штрафами за downtime. Это удобно для продажи, но плохо работает как инструмент управления качеством. Клиент смотрит на «99,9% uptime» раз в квартал и не имеет никакой оперативной обратной связи. Мы отвечаем за формальное число, а не за реальное поведение сервиса под нагрузкой.

Error budget в SLA меняет конструкцию: договариваемся о конкретных SLI (latency, success rate, что-то ещё важное для конкретного сервиса), из них вычисляем SLO, и ежемесячный отчёт - это не «uptime был X», а «бюджет потрачен Y%, вот на что ушло».

Это требует двух вещей:

• Технически - SLO-дашборды для каждого клиента, автоматический отчёт по расходу бюджета. Grafana + Prometheus у всех есть, вопрос в стандартизации recording rules и шаблона отчёта.
• Юридически - переписать раздел SLA в договоре. Юристы наши и клиентские будут смотреть на «error budget» с осторожностью, и придётся объяснять что это значит в практическом смысле. Хотим к середине года иметь обкатанный шаблон на одном-двух клиентах, готовых на эксперимент.

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

Что не берём

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

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

Посмотрим в декабре, насколько план выдержал столкновение с реальностью.