🧠 Skills: Твоя инфраструктура работает. А ты — нет. О выгорании инженера
Коллеги, поговорим о том, о чём не принято говорить на конференциях между докладами про Kubernetes.
Выгорание — это не просто стресс. Это затяжное состояние полного умственного, физического и эмоционального истощения. И это, пожалуй, самая серьёзная и недооценённая проблема в профессии системного администратора.
Я видел это по-разному. Коллега, который держит на себе всю инфраструктуру потому что "он единственный кто понимает как это работает" — это Bus Factor = 1 и верный путь к выгоранию. Коллега, который берёт задачи из личного чата в 23:00 потому что неловко отказать — туда же. Знакомо?
Те, кто не выгорает, научились справляться со стрессом без саморазрушения, просить о помощи когда нужно, и поддерживать баланс между работой и жизнью за её пределами.
Практический алгоритм выхода из режима "я незаменим":
Зачем это нужно:
К 2026 году от администраторов ожидают больше uptime, больше безопасности и больше автоматизации — как правило, с той же командой и меньшим терпением. Чтобы работать в таких условиях годами, а не месяцами — нужно управлять собой с той же методичностью, с которой ты управляешь инфраструктурой.
Итог: Твои серверы мониторятся. Твой CPU-load отслеживается. А кто мониторит тебя? Настрой алерт. Себе.
#skills #burnout #sysadmin #teamwork #карьера #admin_future
Коллеги, поговорим о том, о чём не принято говорить на конференциях между докладами про Kubernetes.
Выгорание — это не просто стресс. Это затяжное состояние полного умственного, физического и эмоционального истощения. И это, пожалуй, самая серьёзная и недооценённая проблема в профессии системного администратора.
Я видел это по-разному. Коллега, который держит на себе всю инфраструктуру потому что "он единственный кто понимает как это работает" — это Bus Factor = 1 и верный путь к выгоранию. Коллега, который берёт задачи из личного чата в 23:00 потому что неловко отказать — туда же. Знакомо?
Те, кто не выгорает, научились справляться со стрессом без саморазрушения, просить о помощи когда нужно, и поддерживать баланс между работой и жизнью за её пределами.
Практический алгоритм выхода из режима "я незаменим":
Шаг 1 — ИНВЕНТАРИЗАЦИЯ НАГРУЗКИ
Фиксируй всё что делаешь 2 недели в любом трекере.
Цель: увидеть реальную картину, а не ощущение.
Шаг 2 — РАЗДЕЛЕНИЕ НА КАТЕГОРИИ
[A] Только я (требует моей экспертизы)
[B] Может делать обученный коллега
[C] Должно быть автоматизировано
[D] Не нужно делать вообще
Шаг 3 — ИЗБАВЛЕНИЕ ОТ КАТЕГОРИИ D
Гарантированно 20-30% задач там.
Просто перестать делать и посмотреть что случится.
Обычно — ничего.
Шаг 4 — АВТОМАТИЗАЦИЯ КАТЕГОРИИ C
Один скрипт, одна задача. Не "потом".
Сейчас. Это инвестиция, а не трата времени.
Шаг 5 — ДЕЛЕГИРОВАНИЕ КАТЕГОРИИ B
Задокументировать -> передать -> принять что будет сделано
не идеально, но достаточно хорошо.
Шаг 6 — ЖЁСТКИЕ ГРАНИЦЫ
Рабочий чат отключается в 19:00.
Это не грубость. Это профессиональная гигиена.
Зачем это нужно:
К 2026 году от администраторов ожидают больше uptime, больше безопасности и больше автоматизации — как правило, с той же командой и меньшим терпением. Чтобы работать в таких условиях годами, а не месяцами — нужно управлять собой с той же методичностью, с которой ты управляешь инфраструктурой.
Итог: Твои серверы мониторятся. Твой CPU-load отслеживается. А кто мониторит тебя? Настрой алерт. Себе.
#skills #burnout #sysadmin #teamwork #карьера #admin_future
❤5👍1
🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.
Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.
#skills #documentation #runbook #sysadmin #teamwork #admin_future
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---
## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"
## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
$ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica
## Шаг 2 — Проверка репликации
$ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.
## Шаг 3 — Failover (только если мастер недоступен)
$ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.
## Шаг 4 — Проверка после failover
$ patronictl -c /etc/patroni/config.yml list
$ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)
## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)
## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni
Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.
Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.
#skills #documentation #runbook #sysadmin #teamwork #admin_future