Есть одна вещь, о которой редко говорят на конференциях. Не Kubernetes. Не CI/CD. Не “переход в cloud-native”.
А то, что самое сложное в инфраструктуре - это вообще не технологии.

Самое сложное - люди.

Потому что одно дело - управлять командой, где все одинаковые. И совсем другое - когда у тебя:

  • DevOps-инженер живет в GitOps и Terraform.
  • Системный администратор до сих пор помнит, как восстанавливать RAID в 3 ночи через mdadm.
  • Сетевой инженер смотрит на Kubernetes как на “эту вашу магию поверх TCP”.
  • DBA физически чувствует боль, когда кто-то делает SELECT *.
  • А молодой джун после курса “Стань DevOps за 24 часа” предлагает “давайте все перепишем на AI-агентов”.

И вот это все - одна команда.

И самое смешное? Оно может работать. Очень хорошо работать.

Но только если перестать строить “идеальную структуру” и начать строить инженерную среду.

Главная ошибка руководителя инфраструктуры

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

Типа:

  • одинаковые процессы,
  • одинаковые KPI,
  • одинаковый подход,
  • одинаковые митинги,
  • одинаковые ожидания.

А потом начинается цирк.

Потому что DBA и SRE думают по-разному. Сетевик и Kubernetes-инженер - тоже. А админ старой школы вообще живет в мире “если работает - не трогай”.

И это нормально.

Инфраструктура - это не “одна профессия”.
Это набор очень разных инженерных культур.

Инфраструктурщик - это не должность. Это психотип и половая ориентация

Это особенно видно в больших командах.

У тебя может быть:

  • человек, который обожает автоматизацию;
  • человек, который ненавидит автоматизацию после одного “terraform apply” в пятницу;
  • человек, который все документирует;
  • и человек, который документирует только собственные страдания в Telegram.

И если пытаться всех сделать одинаковыми - команда развалится.

Нормальный руководитель инфраструктуры понимает:

Не нужно делать одинаковых инженеров. Нужно сделать так, чтобы разные инженеры усиливали друг друга.

Самая токсичная фраза в инфраструктуре

“Ну ты тупой что ли? Сам не можешь разобраться?”

После этой фразы:

  • джуны перестают спрашивать;
  • мидлы начинают молчать;
  • сеньоры начинают скрывать проблемы;
  • команда начинает деградировать.

Потому что инфраструктура - слишком огромная.

Невозможно одинаково хорошо знать:

  • BGP,
  • PostgreSQL,
  • Linux kernel,
  • Ceph,
  • Kubernetes,
  • Vault,
  • Cisco,
  • Proxmox,
  • DNS,
  • backup,
  • GPU passthrough,
  • и еще почему production упал после “небольшого обновления”.

Нормальная инфраструктурная команда строится не вокруг “самых умных”.

Она строится вокруг:

  • обмена знаниями,
  • доверия,
  • и отсутствия страха задавать тупые вопросы.

Хотя честно - самые опасные вопросы обычно задают как раз не джуны, а уверенные сеньоры 😄

Разные поколения - это не проблема

Это вообще отдельный квест.

У тебя одновременно могут работать:

  • человек, который администрировал FreeBSD еще до появления YouTube;
  • инженер, выросший на Docker;
  • и молодой DevOps, который считает SSH “legacy technology”.

И вот тут начинается магия.

Старшие инженеры:

  • знают, как система ведет себя в авариях;
  • умеют мыслить фундаментально;
  • помнят времена без Kubernetes и “managed services”.

Молодые:

  • быстрее адаптируются;
  • лучше автоматизируют;
  • легче изучают новые инструменты;
  • меньше боятся экспериментировать.

И если команда здорова - они начинают учить друг друга.

Если команда токсична - начинается война:

  • “старики ничего не понимают”,
  • “молодые ничего не знают”.

После чего production обычно выбирает сторону хаоса.

Команда - это не набор тасок в Jira

Вот тут многие руководители внезапно открывают страшную тайну:

Люди устают. Даже самые сильные инженеры. Особенно инфраструктурщики.

Потому что:

  • аварии;
  • ночные инциденты;
  • ответственность;
  • постоянный стресс;
  • контекст-переключение;
  • десятки технологий одновременно.

И если команда постоянно живет в режиме:

“давайте еще чуть-чуть потерпим”

то потом начинается:

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

А инфраструктурная экспертиза восстанавливается годами.

Подбор людей - это не “найти самого умного”

Очень часто лучший инженер в команде - не тот, кто знает больше всех.

А тот:

  • кто умеет объяснять;
  • не токсичен;
  • не ломает чужую самооценку;
  • умеет работать в кризис;
  • спокойно признает ошибки;
  • не устраивает культ собственной гениальности.

Потому что инфраструктура - командная игра.

Один “гениальный токсик” способен уничтожить атмосферу всей команды быстрее, чем случайный rm -rf /.

Хотя по последствиям иногда очень похоже.

Ритм работы важнее героизма

Это вообще штука, которую многие понимают слишком поздно.

Инфраструктурная команда не должна жить только на:

  • дедлайнах,
  • авариях,
  • срочности,
  • “сделать вчера”.

Потому что инженерный мозг не может бесконечно работать в panic mode.

Нужен ритм.

Нормальный ритм команды выглядит примерно так:

  • есть понятные процессы;
  • есть предсказуемость;
  • есть время на документацию;
  • есть время на изучение;
  • есть время на техдолг;
  • есть право спокойно подумать.

Да, именно подумать.

Потому что хороший инженер часто выглядит как человек, который “ничего не делает”, а потом за 15 минут решает проблему, которую без него ковыряли два дня.

Руководитель инфраструктуры - это не “главный по серверам”

На самом деле это:

  • переводчик между людьми;
  • стабилизатор хаоса;
  • медиатор между командами;
  • психолог аварийных ситуаций;
  • человек, который принимает удар первым.

И если честно - большая часть работы вообще не про технологии.

Она про:

  • доверие,
  • атмосферу,
  • коммуникацию,
  • зрелость,
  • спокойствие.

Потому что в момент серьезного инцидента команда копирует не знания руководителя.

Она копирует его состояние.

Если руководитель:

  • орет,
  • обвиняет,
  • паникует,
  • ищет виноватых -

команда развалится мгновенно.

Если руководитель:

  • спокойно собирает информацию,
  • распределяет задачи,
  • не устраивает публичные казни,
  • помогает людям думать -

даже тяжелые аварии переживаются сильно проще.

Самое важное правило инфраструктуры

Все мы инженеры.

Не “девопсы против админов”.
Не “сетевики против кубера”.
Не “старые против молодых”.

Все мы просто пытаемся:

  • чтобы системы работали;
  • чтобы данные не потерялись;
  • чтобы ночью никто не проснулся от алерта “Ceph HEALTH_ERR”;
  • и чтобы очередной “маленький фикс” не положил production.

Инфраструктура слишком сложна, чтобы тащить ее в одиночку.

Поэтому сильная команда строится не вокруг технологий.

А вокруг уважения.

Финал, который понимает любой инфраструктурщик

Рано или поздно любая инфраструктурная команда проходит одинаковый путь.

Сначала все спорят:

  • кто умнее,
  • чей стек лучше,
  • чей подход “правильнее”.

А потом приходит production-инцидент в 4 утра.

И внезапно:

  • DBA помогает сетевику,
  • DevOps чинит мониторинг,
  • админ лезет в storage,
  • а самый молодой инженер приносит ту самую идею, которая всех спасает.

И в этот момент все очень быстро вспоминают простую вещь:

Мы не конкуренты!
Мы одна инженерная команда.

А остальное - уже детали.