Дорожная карта на 2017: Kubernetes в production, PostgreSQL вместо MSSQL и подготовка к КИИ

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

Kubernetes: из экспериментов в реальную нагрузку

Весь 2016 год мы провозились с Kubernetes в тестовых контурах. Выпуски 1.3, 1.4 - каждый раз новый повод разобрать что-то глубже: federation, kubeadm, RBAC, network policy. Читали, ставили стенды, ломали. Но живой production-нагрузки на K8s у нас пока нет.

В 2017 году хотим это исправить. Конкретно - взять одного подходящего клиента и запустить пилот: несколько stateless-сервисов, которые сейчас живут на «голых» виртуалках с ручным деплоем через скрипты. Не весь стек разом - один компонент, с нормальным мониторингом и чётким критерием успеха.

Технически к этому готовы: знаем как устроены Deployments, Services, Ingress, умеем настраивать кластер через kubeadm. Готовность инструментально - вопрос другой: нужны нормальные практики по secrets management, по стратегиям rolling update, по сбору логов из подов. Это то, что в стенде не отработаешь - нужна реальная нагрузка.

Главный риск - не технический, а организационный. Команда клиента привыкла деплоить «как раньше». Kubernetes меняет модель работы, и это надо проговаривать заранее, не в момент инцидента в 2 ночи.

PostgreSQL как замена MSSQL: углубляемся

Импортозамещение в госсекторе никуда не делось, реестр ПО продолжает пополняться, и запросы на «уйти с Microsoft SQL Server» от бюджетных организаций стали регулярными. В 2016-м мы сделали несколько таких миграций, и в 2017 году эта история только продолжится.

Что выяснилось за прошедший год: само по себе перенести данные из MSSQL в PostgreSQL - не самая сложная часть. Сложная часть - всё что вокруг. T-SQL-процедуры с нестандартными конструкциями. Приложения, которые завязаны на специфику SQL Server: linked servers, NOLOCK-хинты, нестандартная обработка NULL. Отчёты в SSRS, которые надо куда-то переносить.

В 2017 году хотим систематизировать накопленный опыт. Конкретно: оформить внутреннюю методичку по типовым проблемам миграции T-SQL -> PL/pgSQL, собрать набор диагностических скриптов для оценки сложности миграции до её начала. Сейчас это знание размазано по головам двух-трёх человек - это риск.

Параллельно в октябре мы перешли на PostgreSQL 9.6 в production на нескольких проектах, и parallel query уже даёт результат на аналитических нагрузках. Это меняет разговор с клиентами: PostgreSQL уже не «ну ладно, если нет денег на лицензии», а нормальная инженерная история.

КИИ: готовимся до принятия закона

Законопроект о критической информационной инфраструктуре прошёл первое чтение ещё в октябре. Когда именно его примут - неизвестно, текст ещё может меняться, подзаконные акты не написаны. Но по опыту с 152-ФЗ мы знаем: когда закон выйдет, времени разобраться по-человечески не будет.

Поэтому с теми клиентами из промышленности и энергетики, которые очевидно попадают в периметр субъектов КИИ, мы уже начали подготовительную работу. В 2017 году это направление станет серьёзнее.

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

• Инвентаризация информационных систем и АСУ ТП. Что есть, кому принадлежит, как связано с технологическим контуром. Это занимает больше времени, чем кажется - особенно там, где ИТ и АСУ ТП исторически развивались независимо.
• Предварительная оценка по черновым критериям значимости. Не финальное категорирование - методики пока нет - но понимание, какие системы скорее всего получат высокую категорию и потребуют серьёзных вложений в защиту.
• Аудит текущего состояния ИБ в части, связанной с технологическими процессами. На многих промышленных объектах это область, которую не трогали годами: сегментации нет, обновлений нет, пароли заводские. Знать объём работы заранее - уже половина решения.

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

Что не вошло в приоритеты

Честность требует сказать, чего в плане нет. Нет большого движения в сторону Windows-контейнеров - посмотрели в 2016-м, поняли что экосистема пока сырая для production. Нет агрессивных планов по ELK-стеку - работает, и ладно, большого стимула переходить на что-то другое нет. Нет ничего про ML и «большие данные» - это пока не наш профиль, и насильно его туда тащить незачем.

Три направления - Kubernetes в production, PostgreSQL как полноценная замена MSSQL, подготовка к КИИ. Всё остальное - контекст и сопровождение. Посмотрим в декабре 2017-го, как оно вышло.