ценность, коммитьте в систему контроля версий. Во-первых, можно будет изучать историю; во-вторых, сложнее потерять; в-третьих, можно будет что-то автоматизировать.
Это настолько очевидный совет, что он даже не тянет на материал для этой книги. Но почему же до сих пор не все это делают и продолжают страдать?!
И, конечно же, конфиги с вашего продакшена тоже храните в системе контроля версий. Даже если у вас нет вообще ничего, код вы пишете прямо на сервере, и конфиги правите сразу там же, всё равно начните использовать vsc, чтобы сохранить свой труд.
44. Готовьте заранее план отхода
Если вам нужно сделать в продакшене что-то нетипичное и нерегламентированное, то потратьте немного больше времени на подготовку к этому событию и продумайте план возвращения всего изменённого в состояние “как было”.
На фразу “я всего лишь одну строчку поменяю” я всегда отвечаю: “объём изменений никак не связан с масштабом разрушений”. А уж сколько было историй про неверные изменения конфигов, которые неоткуда вернуть обратно… Или истории про изменения настроек сети, которые инженер производит через удалённое подключение с вполне понятными последствиями в виде полного отсутствия доступа к серверам.
Перед тем, как начать вносить изменения, задайте себе вопрос “А что будет, если…?” и напишите варианты, что может пойти не так и как к этому подготовиться. Вероятно, вам кажется, что это только добавит работы. Отчасти это так, но со временем такая подготовка войдёт в привычку и не будет требовать особых усилий.
45. Если что-то кажется странноватым – вам не кажется
Так называемые “подземные стуки” – вещь очень неприятная. Вроде оно пока не рвануло и катастрофы нет, но не откладывайте разбор подземного стука до момента, когда он ворвётся в вашу дверь. Не откладывайте на завтра то, что могло сломаться уже вчера.
Никто не хочет создавать себе лишнюю работу, это вполне понятно. Давайте назовём этот подход “превентивная надёжность”, что очень точно отражает желание не допускать катастрофы, а приложить подорожник немного заранее.
При возникновении такого рода “подземных стуков” я обычно говорю: “Коллеги, я хочу использовать сегодня день на то, чтобы изучить эту странную штуку”.
Один день это очень небольшая инвестиция в надёжность системы. Если я вижу странное проявление и не могу его объяснить, значит я недостаточно понимаю систему и вот есть возможность изучить её лучше.
В любом случае, на все такие странные проявления нужно заводить тикеты с описанием и собранной диагностикой, чтобы при повторении вернуться к нему и сравнить собранные данные.
А может быть, это было разовое влияние меркурия и ситуация больше никогда не повторится.
46. Ответственны все
У нас есть внутренний процесс разбора инцидентов и я часто разбираю ситуации, когда сломался сервис A, из-за которого сломался сервис B, тем самым сломав сервис C. Сервис B и C занимают позицию “виноват другой сервис
