Управление разношерстной инфраструктурной командой - или как не сойти с ума между DevOps, SRE, SysOps, DBA и сетевиками

Есть в мире Kubernetes вещи вечные.

Например:

• разработчик, который «ничего не менял»;
• DevOps-инженер, который в 02:47 смотрит tcpdump с глазами человека, увидевшего бездну;
• и выбор CNI-плагина, который превращается в религиозный спор похлеще Vim против Nano.

Каждый Kubernetes-кластер рано или поздно приходит к вопросу:

А что вообще ставить для сети?

Есть два типа компаний:

1. Те, кто уже внедрил Kubernetes и теперь ходят с глазами человека, пережившего три переезда дата-центра и миграцию из Oracle в Postgres.
2. Те, кто только собирается его внедрять, потому что «у конкурентов уже есть».

У любого инфраструктурщика и backend-разработчика рано или поздно наступает тот самый момент. Ты сидишь ночью перед очередным сервисом, смотришь на очередной requirements.txt, на старом Flask-проекте, на монолитный Django, на десяток костылей вокруг асинхронности, и начинаешь задаваться вопросом:

"А почему вообще всё это настолько сложно? Может плюнуть и переписать?!"

И вот примерно в этот момент многие приходят к FastAPI.

Есть в жизни инфраструктурщика несколько стадий взросления.

1. Сначала ты создаешь пользователей руками на каждом сервере.
2. Потом понимаешь, что количество серверов растет и начинаешь писать скрипты на bash
3. Позже растешь и начинаешь писать роли на Ansible и Terraform.
4. Бам и у тебя 400 серверов, 120 разработчиков, 20 “временных подрядчиков”, которые работают уже третий год, и один одинаковый ssh ключ на всех стендах (бывает и хуже - одинаковый пароль вида qwe123).

Еще в 2022 году стало понятно, что эпоха “вечного VMware” подходит к концу, но тогда многие компании решили, что время еще есть. Сегодня уже очевидно: инфраструктурная зависимость от VMware превращается в серьезный бизнес-риск, потому что большие VMware-инфраструктуры стали слишком дорогими, слишком сложными и слишком привязанными к экосистеме, правила которой компании больше не контролируют. Проблема в том, что сотни production VM, legacy Windows, SAN, ERP и HA-кластеры невозможно перевезти “за выходные”, особенно если инфраструктура последние десять лет росла по принципу “работает - не трогай”, а значит готовиться к миграции нужно было еще несколько лет назад. Именно поэтому Proxmox VE сегодня перестает быть “решением для лабораторий” и становится реальным способом вернуть контроль над виртуализацией, снизить зависимость от поставщика и успеть переехать раньше, чем миграция превратится в аварийный проект с горящими дедлайнами, ночными rollback и очень нервными разговорами с бизнесом.

Когда компания маленькая, архитекторов обычно нет. Есть разработчик Алеша, системный администратор Димон и руководитель Саша, который говорит сакральную фразу:

"Да что там делать, поднимите сервер, выкатите приложение. Делов-то!".

Потом компания растет. Появляются Kubernetes, микросервисы, Clickhouse, десять команд разработки, пять облаков, семь подрядчиков, бюджеты на миллионы рублей и внезапное осознание:

"Кажется, нам нужен человек, который понимает, как это вообще должно работать вместе".

Так в компании появляются архитекторы.

И именно в этот момент ИТ перестает быть набором случайных серверов и превращается в инженерную систему.