План на 2019: GitOps для Kubernetes, завершение КИИ-категорирования и пилот на Astra Linux

Итоги года написаны, шампанское куплено - самое время сесть и честно сформулировать, что именно мы собираемся делать в следующем году. Не в смысле «нарастим компетенции и расширим портфель», а конкретно: три направления, на которые уходят деньги, время и внимание.

GitOps: пора навести порядок в том, как мы управляем кластерами

Kubernetes у нас в продакшне уже нормально. Но если честно смотреть на то, как мы управляем конфигурациями кластеров - картина неоднородная. Где-то всё живёт в Git и применяется через CI, где-то часть правок уходит через kubectl напрямую и нигде не фиксируется. Когда кластер один - это терпимо. Когда их несколько и у каждого своя история изменений - начинается.

GitOps как подход - не новый термин, Weaveworks давно продвигают идею, что Git-репозиторий должен быть единственным источником истины для состояния кластера. Инструментарий сейчас достаточно зрелый, чтобы это было не экспериментом, а рабочей практикой. Flux мы уже смотрели; в следующем году хотим перевести на такую схему все наши production-кластеры - и свои, и клиентские.

Что это даёт практически:

• Откат к любому состоянию - через git revert, не через «помнишь, что мы меняли в прошлый вторник».
• Аудит-трейл без специальных инструментов - история изменений в репозитории, с автором и временем.
• Onboarding нового инженера - он читает репозиторий, а не расспрашивает коллег о «неочевидных настройках».

Технически это предполагает перестройку части наших CI/CD-пайплайнов и дисциплину с обеих сторон - и от нас, и от клиентских команд. Второе сложнее первого. Но оно того стоит - мы это уже понимаем на основании нескольких инцидентов этого года, когда реконструировать «что и когда изменилось» было нетривиально.

КИИ: закрыть пять проектов категорирования

По итогам 2018-го у нас несколько проектов категорирования КИИ, которые перешагнули в следующий год - кто из-за объёма, кто из-за позднего старта, кто из-за организационных задержек на стороне клиента. Все пять нужно довести до финала: утверждённые акты категорирования, план мероприятий по защите, базовая документация по СОБ.

Практика первых проектов показала: основное время уходит не на техническую часть, а на работу с бизнесом - объяснить, что такое технологический процесс в понимании ФСТЭК, найти людей, которые понимают и ИТ, и производство, получить подписи от нужных руководителей. Это надо закладывать в сроки заранее, иначе потом сдвигается всё.

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

Что точно будет непросто: в части SIEM-решений у многих клиентов накопленная западная инфраструктура и реальный вопрос про сертифицированные альтернативы. Готового простого ответа нет - есть несколько вариантов, каждый со своими издержками.

Импортозамещение: пилот Astra Linux в реальных условиях

Это, пожалуй, самая интересная тема следующего года с точки зрения неопределённости. Astra Linux Special Edition «Орёл» с сертификатом ФСТЭК - инструмент, который мы изучили достаточно хорошо, чтобы понимать, где он нормально работает, а где требует нетривиальных усилий.

В следующем году планируем запустить пилот на реальном проекте в госсекторе. Не стенд, не демо - рабочий сервер или небольшой кластер у клиента с реальными задачами. Цели конкретные:

• Понять, где реально трение - не теоретическое «отечественный дистрибутив», а конкретные точки: совместимость с ПО клиента, навыки администраторов, поддержка вендора, документация.
• Оценить, где Astra нормально заменяет RHEL/CentOS для серверных задач, а где замена тянет серьёзные издержки.
• Накопить практику, которую можно передать клиентам - не пересказ маркетинга, а живой опыт конкретного развёртывания.

Реестр отечественного ПО Минкомсвязи давит на выбор в определённых сценариях, и этот процесс не замедляется. Лучше разобраться сейчас на контролируемом пилоте, чем потом объяснять клиенту на боевом внедрении почему что-то не работает так, как ожидалось.

Что не берём в приоритет

Иногда важнее сказать, чего не планируем. Istio - тащим только туда, где service mesh реально обоснован архитектурно, не везде. Windows Server 2019 - продолжаем практику, но новых направлений не открываем, там всё понятно. Vault в production пошёл у нескольких клиентов - расширяем органически, не форсируем.

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

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