Я занимался разработкой систем последние 12 лет своей жизни. У меня в руках побывало всё. Я видел системы, работающие на COM портах, для передачи данных между терминалами. У меня есть сертификат NEC, подтверждающий тот факт, что я могу программировать их зубодробительные системы, созданные инопланетянами. Я поднимал с колен уложенные облачные фермы и переписывал код на VB6. Мне удалось повидать хорошо отлаженные системы и запутанный ужас, который никак не поддавался дебагу.

В этой статье я расскажу о нескольких основных правилах работы с любой системой. Эти правила не привязаны к определённой системе. Они работают как для монолита, написанного на C# в 2005 году, так и для свежесобранного кластера на кубере.

Некоторым применение этих правил позволит предотвратить головную боль с пересбором упавшей системы за выходные, а некоторым поможет сохранить капиталовложения.

Первое и главное правило администрирования любой системы:

Правило 1: Если это было работоспособным раньше, а сейчас не работает, то нужно приложить все усилия для того, чтобы сделать всё как раньше.

Если у вас есть сервер, который проработал на монолите последние четыре года и внезапно упал, то не надо хаять монолит и говорить о том, что инфраструктура ненадёжна. Нужно поднять сервер.

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

Никто не говорит, что нельзя ничего обновлять. Мы говорим о том, что если в субботу сервер работал, а в понедельник он лежит, то этот сервер можно поднять. У вас был кто-то, кто заставлял этот сервер работать всё это время. В таком случае первым делом надо сделать так, чтобы сервер заработал.

Но для успешного применения этого правила надо убедиться, что мы понимаем все его детали.

Давайте разберёмся с тем, что следует называть работоспособным.

Правило 2: Работоспособным можно называть всё то, что работает. Оно должно работать само по себе, без каких-либо скриптов, уловок и костылей.

Удивительно просто, не правда ли? Да, очень просто. Но к сожалению, в реалиях современного мира IT это не всегда так.

Множество раз я видел подобную картину: заходишь на сервер и сразу видишь баннер

$ cat /etc/motd
This system should be rebooted every Thursday after full moon, when the RAM usage drops under 11%.

Чего? Система должна быть перезагружена вручную, потому что так устроен мир? Или просто потому, что мы не можем признаться в том, что система на самом деле не является работоспособной?

Скорее всего — второе.

Работоспособная программа — это не та программа, с которой программисту надо нянчиться и убеждаться, что она “правильно загрузилась” или “работает как надо”.

Пример:

$ cd ~
$ ls
run-after-reboot.sh
$ cat run-after-reboot.sh
docker exec -it nginx-prod /bin/sh ~/fix-hosts.sh

И действительно, недавно я имел сомнительное удовольствие настраивать Jitsi на производственном сервере. Хотелось всё сделать на контейнерах, чтобы работало как полагается и запускалось с полпинка. Но, как это ни прискорбно, при всех своих положительных качествах мануалы у Jitsi написаны через всем известное место.

Запускаем Jitsi стандартной командой прямо из репозитория:

docker-compose -f docker-compose.yml -f jibri.yml up -d

Что может быть проще? Казалось бы, полностью настроенная, работоспособная система. Всё запускается и работает, кроме одной ма-а-а-аленькой детали. Этот инстанс не умеет записывать видеозвонки через jibri (Jibri = Jitsi Broadcast Infrastructure). После того как вы нажимаете на кнопку “записать”, у вас всё тормозит 30 секунд и выдаётся сообщение, что записывать видео невозможно.

Ок, после четырёх часов лазания по логам мы понимаем, что проблема заключается в том, что контейнер для записи видео пытается подключиться к нашему сайту, на котором работает видеоконференция. Но из-за ошибки в ДНС сервис для записи подключается к XMPP серверу, а не серверу видеоконференций.

Предложенное исправление было очень простым. Зайти на контейнер для записи и сделать echo ‘video.recording.com 172.19.0.2’ > /etc/hosts. Это “исправление” всё исправляло.

Да, бесспорно, записи начали работать. Но было ли это правильным исправлением? Думаю, что у любого контейнеровода просто волосы дыбом подмышками встали бы. К сожалению, в современном мире разработки это сходит с рук.

Вася, вот тебе тикет, почини запись на Jitsi. Вася идёт и чинит запись. Тикет закрывают, всё хорошо. Через два дня тикет переоткрывают. Почему? Все верно, вносить изменения в /etc/hosts на докере это неправильно.

Если вы руководите проектом или командой, вам надо научиться относиться с подозрением к тикетам, которые постоянно воскрешаются. Слушайте пользователей, которые говорят, что “софтина постоянно падает”.

Мы все знаем, что пользователи любят преувеличивать. Существуют и такие, которым нечем в жизни заняться, кроме как отрывать тикеты. А некоторые просто жалуются из-за какого-то чувства мести. Но прикол в том, что компьютерам эти вещи не нужны. Они не умеют врать, жаловаться и мстить. Зато компьютеры умеют писать логи. И когда вы видите таски, которые постоянно открываются и закрываются, или замечаете, что бухгалтерия покупает плакаты с Торквемадой и готова пойти на IT-отдел инквизицией, потому что 1Cка продолжает валиться, то вам пора пойти и выяснить, что происходит.

И… Барабанная дробь… Да! База данных валится каждые 15 часов. Вася додумался перезагружать её в 8 утра, потому что никого нет на работе, но в те дни, когда он этого не делает, бухгалтерия будет жаловаться.

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

Правило 3: Создавать новую систему при наличии уже работоспособной можно только в параллельной установке. Никогда не меняйте и не перенастраивайте работоспособную систему.

Несколько раз мне приходилось работать над модернизацией ERP и CRM систем. Всё было хуже не придумаешь. У вас на руках есть Adobe Air приложение, которое постоянно дёргает веб-сервисы, зашитые в коде.

Перед нами стояла задача обновить старые web backend сервера, поскольку они перестали справляться с нагрузкой. Естественно, их надо было протестировать и убедиться, что новый backend не увалит приложение. Несмотря на то что всё это Adobe Air устарело ещё в 2009 году, мы решили его не трогать просто потому, что оно работало.

Итоговым решением было поднятие varnish сервера, на который мы перевели dns backend серверов. В конфигурации varnish мы перенаправили всё на старые серверы и начали перенаправлять запросы с определённых подсетей на новые серверы. Это дало нам возможность протестировать новые системы.

После месяца тестирования (которое было поразительно скучным, всё просто работало) мы продолжили переводить подсети на новые серверы, и ещё через месяц старый backend был отключён от сети.

Никогда не поддавайтесь жгучему желанию “переписать всё с нуля”, если у вас есть что-то, что работает.

Вам будут обосновывать, доносить, доводить, преподносить, аргументировать, умолять и плакаться в свитер, прося запустить новую систему вместо старой, проверенной. Первым делом, если старая система работала, вы должны её поднять.

Мы подняли новые backend серверы, сделали их работоспособными, установили новые программы, перевели трафик на них и после тестирования отключили старые. В итоге следующий контракт мы получили незамедлительно. Нас попросили переписать Air приложение, под которым всё это крутилось. Это оказалось проще простого.

Сейчас в мире IT наблюдается тенденция на “снижение планки”. В своё время у нас были watchdog, которые считались жуткими костылями. Потом эти watchdog стали чем-то более обыденным, и сейчас в docker у нас есть настройка “автоматически перезапускать приложение”.

Мы привыкли к тому, что что-то может работать не очень хорошо, и вместо того, чтобы это что-то наладить, мы просто отдаём его на откуп этим кнопкам “авторестарта”. Рекомендую сменить подход. Во-первых, человек, который правильно настроил любую систему, будет чувствовать себя крутым. Он будет гордиться своим достижением и чувствовать себя лучше. Человек, у которого система работает через раз, будет выгорать и дёргаться каждый раз при звонке телефона. Он будет жить в мире “скорее всего, что-то скоро упадёт”. Во-вторых, правильно настроенная система требует меньше ухода, соответственно, меньше дополнительных работ.

Хорошо налаженные и отлично работающие системы — это залог того, что ваши нервы будут в порядке.

Правило 4: Делайте выводы о работоспособности чего-то исходя из физических данных, полученных от компьютеров, и никогда не обращайте внимание на жалобы. Жалобы и тикеты должны быть показателем того, куда смотреть, но никогда не работайте на основе данных, полученных из тикета. Эти данные были написаны человеком. Для правильной обработки тикета вам нужно пойти и проверить всё, что в нём описано.

Доскональная проверка позволит вам убедиться, что данные в этом тикете правильные. Никогда не отбрасывайте тикет. Пойдите и найдите реальный источник проблем. Такие вещи находятся в Graylog сервере. Или в zabbix. Или в SolarWinds. Или в Elasticsearch, или где вы там храните логи.

Вам надо научиться смотреть на мир скептически и не верить человеческим эмоциям. В конце концов, вы же не психиатр, вы — инженер. Когда к вам приходят подчинённые и говорят, что “всё хорошо, я всё исправил”, попросите подробности того, что было исправлено. А если вам говорят “да опять эти идиоты из бухгалтерии начудили” — это размахивание красным плащом перед вашим носом. Идите и разбирайтесь, что произошло на самом деле.

Я заметил, что чем больше пены льётся изо рта какого-то администратора, который пытается рассказать вам о том, что проблема произошла не по его вине, тем больше вероятность того, что это-то как раз произошло по его вине.

И все ответы будут в логах. А если у вас нет логов, то вы уже спилили сук, на котором сидите. Когда вас будут обвинять в том, что что-то не работало, вы не сможете со спокойным лицом дать распечатку логов работоспособной системы и попросить показать, где и когда что-то не работало.

Любую компьютерную ошибку можно устранить. В очень редких случаях эта проблема бывает из-за того, что “луна находится не в той фазе”. И если вы осознали, что используете эту фразу больше чем раз в год, то, скорее всего, либо кто-то отлынивает, либо кто-то подделывает логи, чтобы скрыть тот факт, что у него всё из рук вон плохо, а премию хочется.

Правило 5: Хороший инженер может заставить систему работать исправно. Плохой инженер будет выдумывать оправдания.

Причины, которые можно “принять”:

1. У нас землетрясение, ТЦ накрыло (но только в Москве такой причины не будет)
2. Годзилла проснулся и разворотил город
3. Начался зомби-апокалипсис

Причины, на которые не стоит покупаться:

1. Свежее обновление ОС обвалило нашу программу. (А зачем обновляли? Почему не протестировали?)
2. Windows — дно, я же говорил, что нужно пользоваться Linux
3. Linux — дно. Я же говорил, нужно было делать на MacOS
4. MacOS — это та ещё альтернатива дна. Нужно было выкладывать на Windows. (Любые обвинения в адрес продуктов других компаний обычно означают одно из двух: либо обвиняющий не прочитал инструкции, либо просто отлынивает и не разобрался в настройке)
5. Я не знаю, что происходит. (Тебе платят за то, чтобы ты узнавал.)
6. Да не буду я для Пети ничего чинить. (Компьютерам пофиг на эмоции, а ты обслуживаешь компьютеры, не могу понять, причём здесь Петя?)
7. Продукт другой компании — тоже падает. (Ок, у них пусть и падает, тебе платят за то, чтобы ты чинил.)

После того как вы перестанете покупаться на отговорки и будете строго следовать правилу №5 — вы увидите, что народ перестанет выгорать. Более того, ваши сотрудники будут ходить по офисам с прямыми спинами, гордиться и не будут дёргаться от каждого звонка. Вы перестанете кусать кулаки и будете уходить с работы в пятницу с чистой душой, точно зная, что до понедельника вы о работе не услышите.

Это основные метаправила системного администрирования. Опять же, неважно, что, где и как у вас работает. Будь то офис на 10 компов с хабом, кластер кубера или сеть на 10000 человек.

Для того чтобы привнести эти правила в жизнь, вы должны ввести большое количество подлежащих процессов. Работоспособные системы появляются не от взора прекрасных очей и не по щучьему велению.

Лет 7 назад, сидя на Хабре, я наткнулся на книгу “Практика Системного и Сетевого Администрирования” Тома Лимончелли. Неважно, что и как вы администрируете, я очень рекомендую вам найти эту книгу. Поищите на Яндексе по имени автора, она очень легко находится практически в каждом книжном онлайн-магазине в России.

Вышеописанные правила и процедуры, описанные в этой книге, позволят вам сэкономить нервы на администрировании любой системы.

А описанные правила — результат горького опыта. У кого-то язык может повернуться для того, чтобы назвать это «тиранией». Но в словаре есть более подходящее определение этому понятию. Оно называется «дисциплина». И в системном администрировании оно означает разницу между вашим понурым лицом, когда вам приходится объяснять, почему всё опять упало, и между вашим спокойным сидением за компьютером и с чашкой кофе. Как ни странно, но при наличии хорошо настроенных систем жизнь становится лучше.

---

НЛО прилетело и оставило здесь промокоды для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.

— 20% на выделенные серверы AMD Ryzen и Intel Core — HABRFIRSTDEDIC.