Measure once, cut twice

Measure once, cut twice

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

В этом случае из хороших новостей только то, что узнаете вы об этом очень скоро 🙂. Ребята из соседнего отдела техподдержки реагируют быстрее этих ваших модных мониторингов. В этот момент в голове проносятся разные мысли, и ты уже мысленно строишь планы на внеочередной отпуск, бессрочный. Как назло никакого плана быстрого восстановления под рукой нет (кто же думает о disaster recovery plan пока петух не клюнет?). Далее ты немного отходишь от шока и начинаешь исправлять свой косяк. Смотришь состояние бекапов в надежде, что они свежие и рабочие. Если нет, что ж, ты попал.

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

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

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

И еще совет: используй понятный нейминг объектов, чтобы они не вводили в заблуждение о том, к какой подсистеме они относятся.