Приветствую коллеги! Давненько я что то не писал. Попалась тут недавно на глаза вот такая чудесная статья — Ops Lessons. Это сборник 88 уроков, которые нуно устроить людям, работающим в роли Оперейшенс (Operations) — отдел эксплуатации, по сути такие админы в крупной IT инфраструктуре.

Читая эти уроки, у меня возникло ощущение что я читаю документ, написанный кровью. Шучу конечно, какая кровь у айтишников… Но все равно — седые волосы и сгоревшие нервные клетки там точно поучаствовали.

Я решил перевести их и заодно снабдить своими примечаниями и комментариями. Переводы я изначально выкладывал у себя в телеграм канале kazarin.online, по 10 штучек в день. И вот, наконец накопив бОльшую часть правил, решил выложить их в виде отдельной статьи, а потом обновлять ее по мере поступления.

Уроки отдела эксплуатации

1. Отправка уведомлений по электронной почте, это худший механизм мониторинга и уведомления о тревогах.

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

2. Отсутствие сигнала это уже сигнал.

Комментарий: Да. Если ваш сервис перестал присылать информацию в систему мониторинга — это худшее что может быть, потому что вы никогда не узнаете здоров он или нет. Верно  и другое — если вы не собираете какую-то важную метрику о вашем сервисе, вы не узнаете что что-то пошло не так.

3. Важность инцидента определяется числом правил и политик которые вам пришлось нарушить, чтобы его устранить (а не воплями менеджера о том что это «НУ ВАЩЕ КАК СРОЧНО и важно». Потому что если вам позволяют нарушать все правила, это значит что то действительно важное сломалось — прим. пер.).

Комментарий: Например, когда у нас в системе происходит крах, мы часто сначала все чиним а потом фиксируем внесенные изменения постфактум, хотя в обычной ситуации это строжайше запрещено — мы сначала должны зафиксировать все планируемые изменения а потом начать их выполнять

4. Мобильная точка доступа, купленная вами, чтобы вы могли работать вне дома находясь на дежурстве , работает или дома или в офисе (когда и где угодно кроме тех случаев когда она действительно нужна — прим. пер.).

Комментарий: тут ничего не могу сказать, моя меня пока не подводила

5. Тот самый чувак который знает как это работает (и только он знает это — прим. пер.) , прямо сейчас находится в отпуске (причем  обязательно там, там где нет интернета и не ловит телефон — прим. пер.)

Комментарий: обычно это я!)

6. Если после разбора инцидента, соответствующие задачи (чтобы не допустить такого в будущем — прим. пер.), не были созданы и назначены на исполнителей в течении недели, это не будет сделано никогда. Совсем.

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

7. Тот сырой скрипт, который вы набросали на коленке во время предыдущего сбоя, включавший в себя использование expect(1) и ‘ssh -t -t’, теперь является одним из основных инструментов в арсенале вашей команды.

Комментарий: ну у нас такое уже к счастью ушло.

8. Отключение NTP возможно и не было причиной проблемы, но оно и не помогло (тут я сам не до конца понял общий смысл фразы. Наверное по логике это должно звучать так «выключение ntp не было причиной проблемы так что и выключать не стоило»- прим. пер.)

я бы так перевел «NTP being off may not be a root cause, but it sure didn’t help» — «Выключенный NTP может и не быть главной причиной проблемы, но это совершенно точно не улучшает ситуацию в целом (то есть, лучше бы он был включен)»

9. UTC или GTFO. (вот эту шутку я очень долго расшифровывал. GTFO можно перевести на наш как ПШНХ. Типа Или ты используешь на серверах UTC или идешь в пешее эротическое. Пруф https://en.wiktionary.org/wiki/Talk:GTFO — прим. пер.)

Комментарий: Вот тут просто ржал в голосину. Но это был нервный смех. Разные таймзоны на серверах доставляют столько неудобства- кто бы знал!

10. В твоей инфраструктуре используется куда больше самоподписных сертификатов чем ты думаешь. На много больше. Причем в таких местах что ты будешь плакать (когда узнаешь — прим. пер.).

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

11. Самоподписанные сертификаты порождают долгоживущие сертификаты, что в свою очередь порождает пробел в мониторинге валидности сертификатов, что порождает curl -k (игнорирование проверки валидности сертификата — прим. пер.), что порождает пробел в автоматизации развертывания/обновления сертификатов, что в свою очередь порождает самоподписанные сертификаты ( замкнутый круг — — прим. пер.)

Комментарий: все так, все абсолютно так. Именно поэтому лучше уж поднять у себя в сети свой теплый ламповый CA (центр сертификации) или если у вас небольшой проект — использовать LetsEncrypt чем городить такое.

12. Для любых N приложений, как минимум N/2+1 использует ту же цепочку сертификатов.

13. В системе которую вы исследуете (на предмет источника проблемы — прим. пер.), не включает в себя ни один из инструментов с помощью которых вы ее исследуете (говоря по русски, когда надо, инструментов нет под рукой — прим. пер.)

Комментарий: просто жиза. Когда надо, на сервере нет ни nc, ни telnet, ни strace и тд.

14. API без внятного описания реализации и CLI клиента (клиента командной строки — прим. пер.) называют «серым ящиком» (это когда  ты вроде понимаешь как оно работает но на самом деле нет — прим. пер.)

Комментарий: мне кажется тут и комментарий не нужен. Что-то, у чего нет внятной документации и управляется только через скажем web ui — обычно  максимально непонятная штука.

15. Ограниченные командные оболочки не так уж и ограничены как вы думаете (речь наверное идет про урезанные версии bash, типа dash или BusyBox).

Комментарий: абсолютно так. Чтобы привести систему в чувство хватит и их.

16. Очень небольшое число операций по настоящему идемпотентны (идемпотентность это когда число итераций одной и той же операции не влияет на результат — прим. пер.).

Комментарий: попробуйте написать на bash скрипт установки и настройки скажем… агента мониторинга zabbix так, чтобы сколько раз я его не запустил на одной и той же машине подряд, результат был одинаков. А если я буду прерывать его в случайном месте работы а потом запускать сначала? Подумайте над этим… Но я не говорю что это невозможно!

17. «Asserting state» beats «monitoring for compliance» any day.

Комментарий: к сожалению я не смог вдумчиво перевести это правило. Я не очень понимаю смысл словосочетания «Asserting state». Возможно, это устойчивое выражение. Кто подскажет — скажу спасибо!

18. «Раз на миллион — это следующий Вторник» (аналог нашего — «раз в год и палка стреляет», хотя тут скорее о том что пушной зверь подобрался ближе, чем вы думаете — прим. пер.)

Комментарий: угу. никогда не угадаешь откуда тебе прилетит. Особенно радует потом “ну оно же всегда работало”. Вообще системы с высоким uptime — наиболее опасные. Но это тема для отдельного разговора. Если в личку посыпятся вопросы про это — отдельно напишу ответ на канале

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

Комментарий: не согласен! Я это делаю для своего удовольствия и эго 😀

20. Нет никакого облака, это лишь чей то еще компьютер. Нет ничего плохого в том, чтобы использовать командную оболочку для сложных задач — зачастую это проще, быстрее и менее геморойно чем жонглировать различными библиотеками и зависимостями (пытаясь написать тот же функционал на каком-то языке программирования  — прим. пер. )

Комментарий: Все именно так. Ни один из облачных провайдеров, скажем AWS, не творит чудеса. Это те же самые сервера, сети, СХД. Просто они обвязаны чертовой тучей автоматизации и мониторинга. Но и там бывают факапы, поэтому фраза “зачем нам бэкап, мыж в Амазоне сидим” — это глупость. Про решение задач через баш скрипты — ну, классика не умирает. Правда есть одно НО — если вы решаете действительно сложную задачу на bash, помните, что после вас кому то придется читать все это bash-порно… И этот человек может узнать ваш домашний адрес…

21. Нет ничего плохого в Perl (другими словами — нет ничего страшного в том, чтоб использовать Perl  — прим. пер. )

Комментарий: я вообще не вижу проблем в языках. Одни приходят, другие уходят. Да, одно время Perl был популярен в роли скриптового языка для эксплуатации. Потом на его место пришли Python и Ruby, первый победил. Но если у вас есть много инструментов на Perl и вы все еще на нем пишите, это не преступление.

22. Да, мы все временами добавляем $, {, }, и @ в случайные места, заставляя сценарии работать, но все же это срабатывает.

Комментарий: речь идет о правильном использовании переменных, как минимум в bash/shell сценариях, чтобы правильно экранировать все значения, упаковать их и потом изъять. Сложные сценарии вообще плохо читаемы и это минус shell скриптов, поэтому не удивительно что порой приходится чуть ли не наугад подбирать конструкцию.

23. Serverless не существует (это словно нельзя переводить дословно — это термин. Смысл его — без серверные технологии, когда вы запускаете ваш код в облаке напрямую  — прим. пер. )

Комментарий: тут как и с облаком — его не существует. Это миф. Просто где то стоит сервер, который от вас спрятали за кучей оберток и продают вам как serverless. Но чудес не бывает. А вот проблемы случаются.

24. Проблема Y38K уже здесь (Проблема структуры time_t для 32 битных UNIX совместимых ОС. В 2038 году она должна переполниться и сбросить счётчик времени в ноль или в минус, в зависимости от реализации. прим. пер. ). Вы просто ещё не знаете об этом, потому что источники проблемы неравномерно распределены по миру.

Комментарий: если верить Википедии, а у меня нет поводов ей не доверять (и тут вы можете кидать в меня помидорами, но по моему опыту она полезней многих моих преподов в студенческие годы), для этой проблемы нет решения в лоб, кроме как тотальной миграции на х64. Однако очень много систем до сих пор делаются на базе х32 и заменить их будет не просто. Это как миграция с IPv4 на IPv6.

25. Если в расследовании инцидента вы определили «человеческий фактор» как основную причину, значит вы что то делаете не так (имеется в виду что у вас в принципе не верный подход — прим. пер. ).

Комментарий: человеческий фактор всегда есть был и будет. Люди допускают ошибки и это норма. Но раз ошибка была допущена, значит к этому была предпосылка. «Человеческий фактор» это следствие, а не причина.

26. У ваших сетевиков по-любому есть дырка внутрь сети (альтернативный, специальный маршрут, запасной путь и тд. — прим. пер.),о которой не знает команда безопасников.

Комментарий: это просто аксиома и нечего тут комментировать. Если ваш сетевой инженер говорит что это не так, вы недостаточно хорошо его спросили. Доставайте паяльник!

27. Несмотря на то что вы обычно не упоминаете о консольных подключениях и сетях IPMI, все же, внутри себя вы радуетесь что они у вас есть.

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

28. Блокировка трафика для TCP/53 порта (DNS по TCP. Это не совсем стандартно но можно. Хотя по умолчанию это UDP/53 — прим. пер.) может приводить к очень странным последствиям. Не надо так.

Комментарий: по умолчанию, для DNS запросов будет использован протокол UDP, порт 53. Альтернативный вариант по TCP срабатывает либо как резервный, либо необходимо вообще его активировать руками. Однако некоторые одаренные реализации считают себя модными и ведут себя иначе.

29. Где то внутри вашей инфраструктуры есть неизвестный вам сервис (и без сомнения, очень важный — прим. пер.), который очень необычным способом использует DNS для обнаружения входных точек подключения (к другим сервисам — прим. пер.)

Комментарий: тут мне кажется он излишним. Если систему строили не вы с нуля, то под культурным слоем может скрываться жуткое Легаси и адские мастодонты, которые ещё и не такое могут.

30. Не. Совершайте. Никаких. Фокусов. С. /etc/hosts.(вообще не трогайте его если в этом нет необходимости и при этом вы не отдаете себе полный отчет зачем оно и как будет работать — прим. пер.)

Комментарий: на самом деле ничего супер страшного нет, просто этот хак очень быстро забывается и потом вы всей командой пытаетесь понять почему сервер работает иначе чем ожидается. А заглянуть в hosts не все догадаются сразу, ибо это «слишком просто и глупо чтобы быть правдой». Альтернативная версия — «мыж не дебилы».

31. Если ты сломал это — то сейчас ты отвечаешь за это. Если ты починил это — ты навсегда стал ответственным за это.

Комментарий: Просто ты разобрался в том, почему это сломалось и как это работает. Значит теперь ты эксперт по этой штуке и все пойдут к тебе. Вот и все.

32. Выключить и снова включить — вообще то не плохой путь чтобы починить многие вещи.

Комментарий: Как на странно — это так. Особенно в том, что касается Windows. В Linux да и вообще в Unix-like это уже не работает так явно.

33. Файл README.md в Git репозитории вашей утилиты не заменит man страницу, которая должна распространяться вместе с ней.

Комментарий: Для тех кто не в курсе — наберите в терминале “man man” и постигайте дзен. Для тех, кто не в курсе что такое “man man” или “терминал” — поставьте Linux и постигайте дзен.

34. Если ты знаешь что есть какой то документ и ищешь его в поиске, ты найдешь ссылки на любой другой документ кроме искомого.

Комментарий:  мораль сей басни такова — сохраняй в закладки.

35. Документ который ты ищешь был ранее помечен как устаревший и не был перенесен в новую систему управления контентом (возможно имеется виду новая система документации — прим. пер.)

Комментарий: мораль — не удаляй ничего из документации. Никогда не знаешь когда это может пригодиться. Перенеси в другой раздел (хотя это тоже плохо), оставь пометку в заглавии, что документ устарел но не удаляй ни в коем случае!

36. Конечная ваша текущая система управления контентом — отстой. Но она все еще лучше той на которую вы переходите. ( опять же, возможно имеется виду новая система документации — прим. пер.)

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

37. Никто не знает как работает Git, просто периодически все запускают “rm -fr && git checkout”

Комментарий: Неправда на самом деле. Я вот что-то знаю. Есть вообще виртуозы гита. Но да, увы, очень большая часть оперейшенс используют в духе “git commit -am fixed” в мастер ветку и все.

38. Есть ничтожно мало сетевых блокировок и ограничений, которые невозможно преодолеть с помощью смелого и творческого использования проброса портов поверх SSH.

Комментарий: Это так. SSH вообще — мультитул для сисадмина. Дайте мне SSH до сервера в сети и вы дали мне всю сеть по сути. дальше я себе проковыряю все нужное.

39. Это одновременно невероятно полезно но и заставляет беспокоиться (речь похоже о предыдущем высказывании  — прим. пер.)

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

Комментарий: по русски это звучит так — семь раз отмерь, один — отрежь. 

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

Комментарий: есть даже такая фраза, широко известная среди инженеров отдела эксплуатации (сисадминов) — «давай выключим эту ненужную систему и посмотрим, кто прибежит». Дело в том, что ненужные на первый взгляд системы, могут иметь серьезные завязки глубоко в недрах вашей сети или процессов, которые могут явно проявляться например раз в месяц или раз в квартал.

42. «Древний» — очень относительный термин, когда речь заходит о программном обеспечении и протоколах.

Комментарий: мир айти меняется настолько быстро, что порой ты не поспеваешь за ним и считаешь себя вечным студентом. Однако есть вещи которые живут относительно долго и изменения в них имеют совсем другой порядок. Поэтому «древний» — и правда относительный термин.

43. «Устаревший» не означает, что он не используется и на него полагаются.

Комментарий: был у меня на одной из работ сервер, который стоял в цоде. Сервер не мой но я просто про него знал. Так вот, это был сервер компании sun microsystems, на котором стояла freebsd версии 3.х. (на минуточку, последняя 3.5 вышла в 2000-ом году, если память мне не изменяет) и там крутилась какая то самописная система отчётов. Что тут такого спросите вы? Ничего кроме того, что дело происходило в 2014 году…

44. Набор систем в режиме онлайн до и после сбоя центра обработки данных по питанию (отключение электричества  — прим. пер.) может только пересекаться (но не совпадать — прим. пер.). Однако немедленное возвращение в строй некоторых старых систем неминуемо вызовет новый сбой.

Комментарий: тут нужна картинка с Боромиром — «нельзя просто взять и запустить все системы». Во первых, многие из них имеют прямые зависимости. Скажем кластера виртуальных машин стоит запускать только после того, как стартанули все узлы системы хранения данных. А их нужно запускать после того, как у вас нормально запустились все сетевое оборудование…. Виртуальные машины с серверами приложений запускать только после того как запустились сервера баз данных и DNS и ТД.

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

Комментарий: я думаю тут он не требуется. Это является на мой взгляд следствием пункта 31.

46. После первого “это только у меня Слэк упал или у всех грохнулся?” производительность линейно возрастает у всех на протяжении всего времени сбоя.

Комментарий: тут либо я не до конца уловил смысл при переводе, либо slack упоминается как пример, а на его месте может быть любой внутренний сервис. Короче если где-то что то упало, это как то дисциплинирует IT отдел. Типа — «дайте ка проверю, все ли у нас нормально».

47. CAP теорема затрагивает вас сильнее чем вы можете представить (эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить только 2 из 3: согласованность, доступность или устойчивость данных — прим. пер. ). Проблема остановки (невозможность предсказать когда система зкончит переваривать тот или иной объем данных, поданный ей на вход. см описание на Википедии — прим. пер. ) то же та еще сука.

Комментарий: все мы сталкивались с фактом, когда система не верно предсказывает время завершения операции? Например копирование файла. А теперь представьте, что вам нужно закончить резервное копирование до того, как отключится резервное питание серверной стойки… И вы понимаете что прогнозируемое время завершения лишь на минуту меньше, чем прогнозируемый резерв ИБП. Представили? Хреново, да?

48. Свойство сходимости (приведения в некое устойчивое, консистентное состояние — прим. пер. ) Вашей системы не поможет вам в ее отладке, если она не может в него прийти.

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

49. Исходники которые вы читаете прямо сейчас — это уже совсем не тот код, что запущен в продакшене.

Комментарий: потому что исходники — то, что написал разработчик именно этого кода. Это не учитывает влияние новых версий библиотек, версии компилятора и ещё огромной кучи зависимостей, которые подсасывается во первых на момент сборки кода в артефакт, а во вторых, в момент запуска артефакта на сервере.

50. Утилиты strace/ktrace (трассировщик системных вызовов и трассировщик ядра  — прим. пер.) не лгут.

Комментарий: просто потому что они показывают что ваша программа делает именно сейчас на самом деле. Что делает та или иная вызванная библиотечная функция, системный вызов. Просто препарируют процесс на живую и логируют.

51. До тех пор, пока кто то не поиграл в интересную игру с  LD_PRELOAD (переменная окружения, с помощью которой вы можете указать системному компоновщику времени выполнения(ld.so), что он должен загрузить указанные библиотеки раньше других — прим. пер.).

Комментарий: это дополнение к правилу 50 про утилиты трассировки. То есть ситуация, когда они все же могут лгать, хоть и не по своей вине. В результате таких игр с  LD_PRELOAD можно перехватывать какие-либо функции, и заменять их собственной реализацией. Понятное дело, что LD_PRELOAD не работает для SUID-ных программ, иначе вы можете представить что бы началось (собственно, на этом бы ничего не началось, а наоборот, всё закончилось), но даже и без этого с его помощью можно делать много веселья. Самое простое, например, переводить время для отдельных определенных программ или заменять реализацию malloc её более быстрым аналогом tcmalloc. Вообще же, пользуясь LD_PRELOAD, вы можете изменять поведение программы без правки её исходного кода и без перекомпиляции.

52. Бэкап Шредингера — “Состояние любой резервной копии неизвестно до тех пор, пока не будет предпринята попытка восстановления.” — и это еще очень оптимистично.

Комментарий: При настройке резервного копирования недостаточно реализовать его непрерывность и хранение копий отдельно от их источника (да да, есть люди, которые складывают и хранят копии прямо на том же сервере что скажем основная база данных или файл сервер), но еще и проверять что она во первых, может быть восстановлена, а во вторых — содержит то, на что вы надеетесь. 

Например — инженер настраивает резервное копирование базы данных. После сбоя выясняется, что восстановиться из копии невозможно- все архивы битые. Или архивы не битые но внутри у них не дамп БД а каша. Это пример возможности восстановления. Пример с тем, что содержимое соответствует вашим ожиданиям — вы успешно восстанавливается из резервной копии, но тут узнаете что она включает в себя только схему БД, без самих данных. Или включает первые 100 строк каждой таблицы.

53. Для разных ситуаций, в которых вы оказывались, существует комикс xkcd ( или по крайней мере для половины из них)

Комментарий: Вот вам яркий пример от авторов: https://xkcd.com/305/ . П.С. для тех кто не очень в курсе что там происходит, загуглите правило интернета номер 34. 

54. В какой то момент вашей карьеры вы реализуете половину от функционала Kerberos. Это ужасно.

Комментарий: Вообще корни истории растут вот в этом твите.  Идея в том, что если вы начинаете писать свою  “кастомную” систему аутентификации, у вас получится недоделанный Kerberos. Это в том смысле что не надо изобретать велосипеды- есть хороший, проверенные временем и кучей людей решения, которые надо брать и внедрять а не городить свой велосипед.

55. Любой достаточно успешный запуск продукта неотличим от DDoS; любой достаточно продвинутый пользователь неотличим от злоумышленника.

Комментарий: В российском IT это зовется “хабраэффект”. Крупные ритейловые сети например специально готовят свою инфраструктуру перед периодами больших распродаж, например “черной пятницей”. Так что да, популярность — она такая, Ддосит!

56. Отладка любого достаточно сложного продукта с открытым исходным кодом неотличима от реверс инжениринга (этот термин нельзя перевести дословно на русский, поэтому я использую рунглишь.  О том что это — читай википедию) черного ящика.

Комментарий: Любой крупный проект имеет очень сложную и запутанную структуру, легаси, слабо документированные места и т.д. Имеется ввиду что даже если это  открытый проект (open source), это не сильно помогает — все равно получается исследование блэкбокса в какой то степени. Не могу ни подтвердить, ни опровергнуть — не было такого опыта.

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

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

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

59. Начинающий инженер спрашивающий “почему это так” и указывающий на документацию, которая более не отражает реальную картину вещей (устарела, не актуальна — прим. пер.), не менее ценен, чем старший инженер, использующий знания в своей голове.

Комментарий: Золотые слова. Те, кто давно работает, зачастую держит что то (или очень многое) в голове — потому что лень или некогда обновить документацию. Это порочная практика которую нужно пресекать.

60. Ваши героические усилия по обновлению версии ОС во всем вашем парке серверов заканчиваются, когда приходит уведомление о истечении срока поддержки (EOL — End Of Life — конец срока поддержки в терминах IT. Время, когда для какой то версии ПО перестают выпускать обновления, патчи и тп.) той версии на которую вы обновлялись.

Комментарий: Очень жизненное замечание. Поэтому надо сервера не обновлять, а делать новые сборки и автоматизацию развертывания. И просто в какой-то момент переставать ставить старые версии на новые сервера а старые сервера начать заменять на новые (если мы говорим про виртуалки) или просто перезаливать (если говорим про bare-metal)

61. Этот феномен был впервые описан в Аду Данте, как девятый круг ада, четвертый пояс, он же RedHat Canto XXXIV.

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

   62.Контейнеры создают не меньше проблем чем решают.

Комментарий: Это так. Они вводят дополнительные уровни абстракции (Overlayfs, cgroups, namespaces), которые обычно идеально работают в лабораторных условиях но в реальных боевых условиях могут добавить энтропии и в итоге дебаг усложняется. Я уже писал заметку об этом/

63. Наиболее ловкий ход со стороны эксперта, нанятого для поддержки того стороннего продукта, представляющего из себя черный ящик (то есть абсолютно закрытую для вас систему, которая непонятно как работает, как ее чинить и тд — прим. пер.), это фраза “дайте ка я свяжусь с тех поддержкой”

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

64. Кто то когда то уже сталкивался с такой же проблемой, однако не удосужился опубликовать решение.

Комментарий: Поэтому если вы решили какую-то, на ваш взгляд не очевидную проблему, выложите решение в блог, на stackoverflow или еще куда то, чтобы до него дотянулись щупальца вездесущего Google. Вам скажут спасибо!

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

Комментарий: Потому что нужно к любой автоматизации нужно делать автоматическое тестирование и добиваться  100% прохождения для разных тест-кейсов.

66. Бюджет на капитальные расходы (CAPEX ) всегда растет, а вот бюджет на операционные расходы- сокращается. (OPEX)

67. Капитальные расходы могут быть разумно оценены, а вот операционные- лишь приблизительно.

68. Даже если вы назовете вашему менеджеру оценку времени в два раза больше чем нужно (на всякий случай — прим. пер), это не сработает, так как ваш менеджер поржет и уменьшит ее обратно, потому что он уже обещал такой срок своему руководству.

Комментарий: потому что у бизнеса свои сроки и требования. Хотя хороший менеджер все же должен накидывать к срокам 30% на форс мажор.

69. Все ваше квартальное планирование превратится в тыкву после следующей очередной реорганизации.

70. Большая часть того что вы на самом деле делаете, не совпадает с вашими OKR  (поставленные цели и ключевые результаты — прим.пер.)

Комментарий: позволю себе процитировать Википедию: «Суть метода состоит в том, что определяется несколько сложных ключевых целей на некоторый промежуток времени (квартал или год), притом они задаются как для всей компании (или отдела), так и для конкретных сотрудников; для каждой из поставленных целей определяются 3–5 измеримых параметров, по которым можно судить о достигнутых на данном направлении результатах». У нас тоже используется этот метод. Каждый из нас хочет развиваться как специалист, изучить новое, потыкать новую игрушку или технологию. OKR позволяет компании и сотруднику договориться, определив общие интересы. Однако как уже сказано выше, на практике бОльшая часть вашей ежедневной работы не совпадает с этим.

71. Рекурсивное применение принципа Парето — это на удивление хороший способ определить оценить ваши невысокие результаты, определить ваши высокие цели и оценить необходимые усилия.

72. Конечно, чтобы быть честным, это работает только в 80% случаев. Примерно.

73. Менеджмент всегда будет рад потратить тонну денег на сторонних консультантов лишь затем, чтобы они сказали им то, что вы говорили им годами.

Комментарий: к счастью это не всегда правда, однако я тоже с таким сталкивался. Значит ваш голос перестал считаться или никогда не считался весомым. Свои сотрудники вечно жалуются на что то… а тут солидные дяди со стороны сказали.

74. Руководство скорее инвестирует в изобретение нового квадратного колеса, чем в починку старого круглого.

Комментарий: новое квадратное колесо это новые фичи, которые могут принести новые деньги. А старое круглое — это уже текущие операционные расходы. Оно же едет? Едет. Значит ещё проедет. Вот когда остановится и потянет за собой прочее тогда и поговорим. С другой стороны возможно вы неверно доносите все риски до руководства.

75. В любой организации, практикующей непрерывную интеграцию, половина всех коммитов заключается в подделке тестов в CI.

Комментарий: Подхачить тест или подставить костыль чтобы “ну вот щас, на время, потом поправим” всегда кажется проще и быстрее, чем сделать правильно.

76. Хорошие практики разработки софта не всегда хорошо применяются в ops. 

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

Комментарий: Недостаточно просто иметь процесс, обязывающий кого-то смотреть чужой код. Нужно чтобы это было осознанно и вдумчиво, чтобы люди относились к этому ответственно и понимали зачем это нужно. Причем обе стороны — и ревьюер и тот, чей код ревьюят.

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

Комментарий: Посмотрите на все новые фреймворки разработки, на тот же докер, оркестраторы. да блин даже банальная виртуализация наращивают нам все новых и новых слоев вокруг железа, которое само по себе тоже не самая простая вещь.

79. Реальные изменения могут быть внедрены только выше 7 уровня.

Комментарий: Это очень тонкая шутка. Имеется  в виду что реальные изменения это архитектура системы, это процессы, это идеология и философия разработки и поддержки- то есть то что явно за пределами 7-ми уровней модели OSI. Есть так называемый 8-ой уровень модели OSI, который зову еще Организационным или Политическим. Почитайте, идея вам понравится.

80. Нет никакого “продакшена”, есть лишь еще один “стейджинг” (тестовое пред продакшн окружение, которое максимально похоже на него по конфигурации и в котором проводится финальное тестирование перед выходом новой версии “в свет” — прим.пер.)

Комментарий: Несмотря на то что стейдж стараются делать как можно ближе по конфигурации к продакшену, все равно добиться полного сходства нельзя — не те паттерны нагрузки, не такой же дамп данных в базе и тп. Поэтому порой встречаются ошибки которые можно отловить только на проде. Вот и получается что прод это еще один стейджинг. 

81. Все ваши источники истины лгут

Комментарий: потому что как бы вы не старались, не получится создать на 100% достоверный источник информации. Информация со временем устаревает, теряет актуальность, если говорить о базе знаний. база инвентаризации накапливает ошибки и белые пятна и тд. 

82. К тому же они не полны ( дополнение к предыдущему правилу 81 — прим. пер).

83. pcap или ничего не было ( в смысле предоставь запись событий в виде дампа сетевого трафика в формате pcap или считай что у тебя нет доказательств — прим.пер.)

Комментарий: в споре двух инженеров/команд должны быть железные аргументы. И это либо логи, либо дамп сетевого трафика. А лучше и то и то. Но Pcap файл несомненно самый весомый аргумент.

84. grep(1) круче Splunk ( во всяком случае я так понял знак > )

Комментарий: Я спланком конечно не пользовался, но мне нравится ELK. Однако тут тонкий юмор что простые и проверенные инструменты обычно лучше.

85. Мультипоточность редко стоит той сложности, которую она привносит.

Комментарий: Потому что, чтобы управлять несколькими потоками, синхронизировать их данные, контролировать и оберегать от блокировок придется написать кучу кода и еще больше его оттестировать. Может проще запустить несколько экземпляров приложения?

86. Параллелизм не параллелен

Комментарий: Да, это все равно псевдопараллелизм. Даше с многоядерными процессорами и даже с мульти процессорными системами. Все равно на самом деле есть ведущий процесс, ядро, процессор, контроль со стороны ОС, планировщики и тп.

87. Простота — вежливость королей.

Комментарий: Можешь сделать ил оставить какое-то решение простым и понятным- сделай это. Принцип KISS 

88. Никто на самом деле не знает что вы делаете