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

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

Обмен информацией о причинах и продолжительности проблемы, а также о том, можно ли или следует предпринять шаги для предотвращения проблемы, являются важными и стоят того, чтобы создать отдельный процесс вокруг них. Я вспомнил об этом сегодня, когда пошел пить ледяной чай в Panera. На автомате для газировки кнопка Dr. Pepper была с рукописной запиской, что она “закончилась, извините!”. Я не пью Dr. Pepper, и даже если бы пил, длинное объяснение причин, вероятно, меня не обрадовало бы, и если проблема не будет исправлена в ближайшие две минуты, то оно, вероятно, меня бы не заинтересовало.

Забавно представить, что происходит за кулисами; менеджер/складской работник забыл заказать, человек, отвечающий за газировку, заболел и не смог выполнить свой маршрут, будут ли они держать “дополнительное” количество на складе на всякий случай? Или просто “у нас закончилось”, и оно будет здесь позже сегодня, этого достаточно? Когда я увидел эту рукописную записку, мне на лицо появилась улыбка, потому что я сделал эту фотографию довольно давно в Chipotle для будущей статьи в блоге. Они планировали на случай сбоя, справились с ним и добавили немного самоиронии.

Обмен сообщениями имеет значение. Подумайте о том, что вы показываете своим клиентам, когда происходит сбой. Представьте, что ситуация поменялась, вы бы подумали “оправдания”, “вертеться”, “отрицание”? Обмен информацией о сбоях требует отказа от гордости и принятия риска и последствий. Странно, но чем спокойнее и прямее вы справляетесь с этим, тем меньше последствий.

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

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

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

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

Помните, что планирование на случай сбоя не является признаком слабости или лени. Это проактивный подход для обеспечения бесперебойной работы вашей среды SQL Server. Так что, в следующий раз, когда вы столкнетесь с сбоем, подумайте о сообщении, которое вы передаете. Возьмите на вооружение подход Chipotle и справляйтесь с этим с достоинством, смирением и юмором.