Каков алгоритм действий при полном отказе сервера

А, слушай, вот ты сидишь такой, чаёк попиваешь, и тут — бац! — всё накрылось медным тазом. Сервак взял и сдох, как последний мартышлюшка. Паника? Да, блядь! Но главное — не бздеть, а действовать по плану, иначе наебнёшься так, что мало не покажется.

Фаза 1: Ёбнуться и проверить — точно ли это не твои глюки?

1. Не тупи, подтверди отказ. Первым делом — не лезь слепо перезагружать. Может, у тебя просто интернет отрубился, или ты криво в консоль тыкаешь. Проверь доступ с телефона, через мобильную сеть. Глянь на внешние мониторинги типа UptimeRobot — если у них тоже красное, ну, поздравляю, пиздец пришёл.
2. Завались в Grafana/Zabbix. Смотри, что было перед падением. CPU в потолок ушёл? Память кончилась и OOM Killer всех поубивал? Диск забился под завязку? Или, может, на тебя хуй с горы пришёл в виде DDoS-атаки? Графики всё покажут.
3. Провайдер не ебёт? Если сервер в облаке (AWS, GCP), сразу лезь на их страницу статусов. Бывает, что у них весь регион накрылся, и ты тут со своим reboot как хитрая жопа — только время теряешь.
4. Орви команду. Не геройствуй в одиночку. По рации, в чат, дымовыми сигналами — дай знать, что всё хуёво. Пусть все в курсе, что ты уже в процессе, а то потом спросят: «А че молчал, пидарас шерстяной?».

Фаза 2: Диагностика, или «Давайте залезем в эту горящую хату»

1. Подключиться — наше всё. Ломись по SSH. Не пускает? Ебушки-воробушки, пора включать аварийную консоль (KVM/VNC), которую провайдер даёт. Это как чит-код, чтобы заглянуть серверу в ебало, когда он уже не дышит.
2. Читай логи, они всё расскажут. Пролез внутрь — не хера не трогай, сначала смотри:
   • dmesg — тут ядро орёт, если было что серьёзное: kernel panic, диск отвалился, оперативка глючит. Кричит «ПОШЛО ВСЁ НАХУЙ» системным языком.
   • journalctl -xe или старые добрые /var/log/syslog — тут все системные вопли и предсмертные хрипы сервисов.
   • /var/log/auth.log — вдруг это не баг, а фича? Может, тебя взломали и всех повыключали. Подозрение ебать чувствую, если логины в 3 ночи из Нигерии.
3. Быстрое «костыльное» решение. Если время жмёт, а причина неочевидна — да похуй, ребутни сервер (reboot). Часто помогает, как волшебный пендель. Сервис оживёт, а ты потом, в спокойной обстановке, будешь разбираться, что за пиздопроебибна случилась. Это не решение, а отсрочка, но бизнес не стоит.
4. Проверь, что встало. После ребута не расслабляйся. Команда systemctl status nginx postgresql redis — твои лучшие друзья. Убедись, что всё поднялось, а не висит в статусе failed, как последний полупидор.

Фаза 3: Разбор полётов, или «Чтобы завтра не было так же охуенно больно»

Всё работает? Отлично, но это не конец. Теперь надо понять, какого хуя это произошло, чтобы не повторялось.

• Найди корень зла (RCA). Копайся в логах и метриках глубже. Это был твой код, который съел всю память? Конфигурационная хуйня? Апдейт ядра, который всё сломал? Надо докопаться.
• Задокументируй весь этот цирк. Напиши пост-мортем: что упало, когда, как реагировали, что делали, сколько времени проёбывали. Это не для начальства, а для будущего себя, чтобы через полгода не гадать: «А че тогда было-то?».
• Придумай, как сделать лучше. Создай задачи. Не хватало алертов? — Настрой мониторинг, чтобы он орал раньше, чем всё рухнет. Узкое место в коде? — Оптимизируй. Один сервер — точка отказа? — Задумайся про отказоустойчивость, high-availability кластер. Чтобы в следующий раз, когда хуй с винтом прилетит, система просто хмыкнула и продолжила работать.

Вот такой, блядь, невесёлый, но необходимый танец с бубном. Главное — системность и холодная голова, даже когда внутри всё орет «ебанный рот этого казино!».