Итоги 2019: Ansible в продакшне, первые Kubernetes-кластеры и КИИ-проекты, которые растянулись на весь год

Январь - хорошее время сесть и честно разобраться, что получилось, а что нет. В конце 2018-го мы ставили цели: GitOps, завершение КИИ-категорирования, пилот на Astra Linux. Как оно вышло - сейчас расскажем.

Ansible: наконец-то по-настоящему в продакшне

Это, пожалуй, самый тихий и при этом самый весомый сдвиг года. Ansible у нас и раньше использовался - но честно говоря, больше как замена bash-скриптам с приятным YAML-интерфейсом. В 2019-м произошло что-то другое: несколько клиентов перевели реальные production-конфигурации под управление плейбуков. Не «поставить пакет», а «описать состояние серверного парка и применять его по расписанию».

Что это изменило на практике:

• Конфигурационный дрейф - одна из тех проблем, которую замечаешь не сразу, а когда что-то сломалось и надо разобраться «когда и кто это поменял». С Ansible и идемпотентными плейбуками этот вопрос стал отвечаемым.
• Onboarding новых серверов сократился до «запусти роль». Звучит банально, но разница ощутима, когда нужно поднять десяток машин после инцидента или перед нагрузкой.
• Ansible Tower (теперь AWX в open source-варианте) дал клиентам интерфейс: они запускают плейбуки сами, видят логи, не пишут нам каждый раз. Это перестройка процесса, не только инструмент.

Из неожиданного: самая частая точка трения - не Ansible, а привычки команд. Люди, которые годами правили конфиги руками через SSH, поначалу смотрят на «нельзя просто зайти и поменять» как на ограничение, а не на порядок. Постепенно проходит.

Kubernetes: первые кластеры у клиентов

В 2018-м Kubernetes стал нашим внутренним стандартом. В 2019-м он пошёл к клиентам - и это совсем другая история.

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

Сетевая модель всегда вызывает вопросы у людей, которые привыкли к «VM с IP-адресом». Объяснять разницу между IP пода и IP сервиса приходится несколько раз и на разных уровнях - от разработчика до сетевого администратора.

Stateful workloads - тема, с которой мы в 2019-м были аккуратны. Базы данных в Kubernetes работают, но Persistent Volume, storage class, резервное копирование - всё это требует внимания, которое у клиента не всегда есть в нужном объёме. Нескольким клиентам мы прямо сказали: вот ваши stateless-сервисы едут в кластер, а Postgres пока остаётся на виртуалке. Не потому что не умеем - а потому что так надёжнее в конкретных условиях.

Мониторинг - Prometheus Operator плюс Grafana. Здесь, наоборот, всё прошло гладко: клиенты быстро оценили готовые дашборды и алерты, которые работают из коробки после установки.

Облачные бюджеты у нескольких клиентов в 2019-м выросли - в основном на managed-сервисы у российских провайдеров. Kubernetes там идёт как часть сопровождения инфраструктуры: мы следим за кластером, обновляем, разбираем инциденты. Для команд без выделенного DevOps это рабочая модель.

КИИ: почему проекты растянулись на весь год

Если честно - мы в конце 2018-го рассчитывали закрыть несколько проектов категорирования в первом квартале. Закрыли в третьем и четвёртом. Это не провал, но повод разобраться.

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

Что мы поняли про эти проекты:

• Категорирование начинается не с ИТ-систем, а с производственных и бизнес-процессов. Половина объектов КИИ, которые в итоге попадают в акт, на старте проекта вообще не фигурировала в списке ИТ-отдела - потому что одни думают про серверы, а другие про технологические линии.
• Приказ ФСТЭК №239 - это не документация, это требования к реальным системам защиты. Несколько клиентов воспринимали категорирование как «сделать бумаги». Приходилось объяснять, что за бумагами идут требования к СЗИ, к персоналу, к процессам.
• Сроки регулятора - отдельная история. Плановые проверки сдвигались, ответы приходили дольше ожидаемого. Это реальность работы с государственными структурами, и закладывать на это время в плане - не пессимизм, а опыт.

К концу года несколько проектов категорирования закрыты, у части клиентов начался этап реализации мер защиты. Это уже другая работа: подбор сертифицированных СЗИ, интеграция с ГосСОПКА, выстраивание процессов мониторинга и реагирования.

Что не случилось

Astra Linux пилот - запустили, но позже, чем планировали, и в меньшем масштабе. Реальный опыт получили, выводы есть, но до конца года дотянуть всё запланированное не вышло. Перекатится в 2020-й.

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

Что берём в 2020-й

Если коротко: Kubernetes-кластеров станет больше, Ansible-практика идёт органически, КИИ-проекты переходят в фазу реализации. Облачная миграция - тема, которая в 2019-м нарастала медленно, а в разговорах с клиентами звучала всё чаще. Посмотрим, во что это выльется.

Декабрь следующего года покажет.