Я всё сломал2
Доброго времени суток, коллеги.
Я сисадмин и я всё сломал.
Интересно услышать ваше мнение.
Небольшая предыстория обо мне.
Я отработал 15 лет в бюджетной организации, попал туда, для выполнения практики, из университета. Начинал с поддержки рабочих мест и в итоге стал сисадмином. Моя зарплата на этой работе меня никогда не устраивала.
Почему 15 лет? Все просто. Низкая ЗП, естественно, заставили меня искать другую работу. Но провалив несколько собеседований, я потерял веру в себя, взрастил в себе комплексы и попал в «зону комфорта». Но резюме на HH, хоть и не сразу, я всё же разместил и регулярно получал уведомления о подходящих мне вакансиях. Несколько лет назад, я нажал «откликнутся» в одной из вакансий и пройдя все собеседования, получил офер и новую работу.
И вот это случилось, я совершаю фатальную ошибку, которую до сих пор не могу объяснить. Подумав об одном, я делаю другое, игнорируя всё, что мне выдаёт установщик ПО, я перетираю данные на дадасторах платформы виртуализации. Это десятки ВМ с кучей сервисов, это десятки ТБ данных. Полностью парализована работа крупной компании в зоне ответственности.
А теперь эти МЫСЛИ, всё то, что держало меня на одном месте годами, все мои страхи, всё как будто подтвердилось, голос в голове говорит: «вот, я же говорил тебе, ты ноль, куда ты лезешь».
На данный момент, я всё восстановил из РК. Сам СРК тоже я сопровождаю, как и всё остальное. ВМ восстановил в течении суток. На файловый сервер ушла неделя, восстанавливал ресурсами, по приоритетам от заказчика.
КИ закрыт. Осадочек остался.
UPD:
Всем большое спасибо, за оставленные комментарии. Я всё внимательно читал. Основной посыл в комментариях был сделан на планирование работ. Плана действий, расписанного по пунктам, плана отката в случае ошибок, всего этого не было в моём случае. Была цель и последовательность действий, которые были у меня в голове. Самоуверенность, усталость, слабоумие и отвага, итог я уже описал выше. Выводы я сделал. Коллеги, не повторяйте моих ошибок. Всех с новым годом! И да, делайте резервные копии. :)
«Семь раз отмерь, один – отрежь»
было дело, в Англии учил англичан английскому ITIL.
правило номер 1: все является изменением! установка сервака суть изменение пустой стойки на занятую. обновление оси - тоже изменение от версии N до версии N+x. добавление одной строчки в конфигурационном файле - изменение!
правило номер 2: проверяй все изменения в нерабочей среде. программисты проверяют свой код, да? модный нонче DevOps суть тот же подход успешного программирования в инфраструктуре. для этого нужно иметь нерабочую/тестовую среду. последние 20+ лет тайна моего успеха в том, что или проверяю изменения на своих серваках дома, или выкраиваю тайком на работе маленький уголок для проб и ошибок. все удивляются почему такой смелый в критичные минуты, не зная, что последние месяц-полтора составлял карту всех возможных граблей и чертал обходы мин замедленного действия.
правило номер 3: до начала работ должен быть список всех компонентов затрагиваемой системы, описание внешних связей с другими системами, список ответственных за каждую систему и каждый ее компонент людей, и план проверки работоспособности. в случае внешних для компании связей, контакты для связи с технарем и с административным руководителем.
правило номер 4: всегда и во всем должен быть не только план движения вперед, но и план откатки в выходное положение. будь это резервные копии, будь это выключение старой виртуалки и проведение работ на копии виртуалки с возможностью сноса оной в любой момент.
правило номер 5: обязательно дай коллеге или руководителю прочитать твой план действии до начала работ. свежий взгляд со стороны и/или прочтение более опытным специалистом может уберечь от ошибок. если коллеги нет и начальник в этом не разбирается, то руководство сами себе злобные буратины - у серваков запасные БП, сетевых карт добавляют попарно, коммутаторов тоже парами устанавливают, а человек всего лишь один = SPoF.
правило номер 6: получи одобрение своего плана работ в письменном виде. это не только снимает/разделяет ответственность. одобряющий потребует досконального объяснения каждого шага, потому что уже сам в ответе. пошаговое объяснение помогает выявить возможных ошибок плана работ. во время внесения изменении в особо ответственных системах применяй правило "четырех глаз": один пишет команду согласно плану, второй проверяет правильность комманды вместе с всеми параметрами оной и дает добро на выполнение оной, и только тогда первый жамкает клавишу Enter или щелкает мышью на бутон ОК.
правило номер 7: обязательно проверить все системы до начала работ! чтобы после начала не было обвинении "раньше все работало", хотя кто-то сломал его пару лет назад и до сих пор никто не заметил. проверить еще раз после внесения изменении работоспособность всех затронутых компонентов системы и связанных с ними других систем. получить потверждение от потребителей системы, что оная работает штатно.