Первые 60 секунд инцидента на проде: остановись, определи масштаб, сопоставь

Автор: Jose Manuel Jurado (MICROSOFT), Lessons Learned #555: The First 60 Seconds of a Production Incident: Stop, Scope, Correlate;

Когда кто-то говорит: «База данных упала», начните с четырёх вопросов: что именно отказывает? кто или что затронуто? когда это началось? что изменилось или коррелируется с этим моментом? Затем позвольте доказательствам определить следующий шаг. Остановись. Определи масштаб. Сопоставь. Устраняй с доказательствами.

Когда начинается критический производственный инцидент, первое сообщение, которое мы часто получаем, звучит примерно так: «База данных упала».

В этот момент всё внезапно становится срочным.

• Инженеры открывают панели мониторинга.
• Кто-то начинает проверять журналы.
• Другой просматривает CPU и память.
• Кто-то ещё спрашивает, было ли развёртывание.
• Тестируются соединения.
• Запрашиваются метрики.
• Связываются с командами.

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

Поработав над множеством производственных инцидентов, один урок становится всё более очевидным: первые 60 секунд — это не про решение инцидента. Это про определение инцидента.

Расплывчатое описание проблемы может направить диагностику во множество разных сторон. Точная формулировка проблемы резко сокращает пространство расследования.

В этой статье описывается простой подход, который можно применить в первые моменты инцидента: Остановись. Определи масштаб. Сопоставь.

Page Life Expectancy — это не то, что вы думаете…

Автор: Paul Randal, Page Life Expectancy isn’t what you think…

Существует много споров о счётчике производительности Buffer Manager — Page Life Expectancy, в основном вокруг того, что люди продолжают цитировать 300 в качестве порога для начала беспокойства о проблеме (что в наши дни является полной ерундой). Это слишком низкое значение, чтобы быть точкой, на которой стоит начинать беспокоиться, если ваш PLE падает и остаётся на этом уровне. Джонатан предложил лучшее число, основанное на размере вашего буферного пула — см. нижнюю часть его статьи здесь.

Но не поэтому я пишу сегодня: я хочу объяснить, почему в настоящее время Page Life Expectancy в большинстве случаев не даёт вам полезной информации.

Представления производительности в реальном времени, которые упрощают устранение неполадок

Автор: Pinal Dave, Real-Time Performance Views That Make Troubleshooting Easier

Запрос, который вчера выполнялся за 200 миллисекунд, сегодня выполняется 14 секунд. Команда приложения заметила это раньше, чем инструмент мониторинга. К тому моменту, когда кто-то открывает сервер базы данных, в представлении активных запросов находится 47 сеансов, три из них заблокированы, и один из них удерживает блокировку, которая открыта уже шесть минут. Никто не может сказать вам, что делает этот сеанс, кому он принадлежит и безопасно ли его завершить. Это не проблема оборудования. Это проблема видимости. И она встречается чаще, чем следовало бы. Давайте поговорим о представлениях производительности в реальном времени, которые упрощают устранение неполадок.

Контроль состояния распределённой группы доступности: T-SQL и Zabbix

Автор: Pablo Echeverria, Distributed Availability Group Health: T-SQL and Zabbix

После создания распределённой группы доступности по шагам из моей статьи «SQL Server 2022: Распределённая группа доступности без кластера», как проверить, что синхронизация между дата-центрами в порядке?

В SQL Server Management Studio, если щёлкнуть правой кнопкой по распределённой группе доступности, вы заметите, что нет панели мониторинга, подтверждающей корректную синхронизацию данных между дата-центрами:

Даже если проверять панели первичного и вторичного дата-центров по отдельности, вы не увидите, есть ли проблема «между ними».