Ответ на пост «Я всё сломал»⁠⁠2

«Семь раз отмерь, один – отрежь»

было дело, в Англии учил англичан английскому ITIL.

правило номер 1: все является изменением! установка сервака суть изменение пустой стойки на занятую. обновление оси - тоже изменение от версии N до версии N+x. добавление одной строчки в конфигурационном файле - изменение!

правило номер 2: проверяй все изменения в нерабочей среде. программисты проверяют свой код, да? модный нонче DevOps суть тот же подход успешного программирования в инфраструктуре. для этого нужно иметь нерабочую/тестовую среду. последние 20+ лет тайна моего успеха в том, что или проверяю изменения на своих серваках дома, или выкраиваю тайком на работе маленький уголок для проб и ошибок. все удивляются почему такой смелый в критичные минуты, не зная, что последние месяц-полтора составлял карту всех возможных граблей и чертал обходы мин замедленного действия.

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

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

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

правило номер 6: получи одобрение своего плана работ в письменном виде. это не только снимает/разделяет ответственность. одобряющий потребует досконального объяснения каждого шага, потому что уже сам в ответе. пошаговое объяснение помогает выявить возможных ошибок плана работ. во время внесения изменении в особо ответственных системах применяй правило "четырех глаз": один пишет команду согласно плану, второй проверяет правильность комманды вместе с всеми параметрами оной и дает добро на выполнение оной, и только тогда первый жамкает клавишу Enter или щелкает мышью на бутон ОК.

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