У меня только что произошел сбой в работе сервера в 4.59 утра в воскресенье, и я просматриваю наши записи о времени безотказной работы, начиная с 2006 года, за исключением 4 отключений из 20, произошедших между 23:00 и 6:00. (Рассматриваются только незапланированные простои на веб-серверах и серверах баз данных, а не на серверах приложений во внутренней локальной сети.)
Другие также находят подобное поведение для своих серверов? Это просто случайность?
Редактировать: Это произошло из-за того, что между 23:00 и 6:00 произошло так много отключений (это незапланированное, а не плановое обслуживание и произошло на нашем оборудовании, а не в сети провайдера), что заставило меня задуматься, что только мы ...
Серверы наиболее загружены с точки зрения посетителей между 13:00 и примерно 22:00, в то время как резервное копирование базы данных происходит в течение дня, а большое резервное копирование (где сжатие использует больше ресурсов ЦП) происходит примерно в 4:30 каждое утро. Но сбои происходили в любое время в течение этого окна (также эти 20 сбоев являются событиями, происходящими на 1 из 5 серверов или 2 брандмауэрах - около трети из которых были результатом отказа жестких дисков 2 разных машин). Нет ничего, что указывало бы на то, что сервер что-то делал конкретно, потому что это было ранним утром.
Типичное «рабочее время» - не более 40 часов в неделю. В некоторых частях мира меньше. Всего в неделе 168 часов. 40/168 = менее 24% времени в неделе составляет «рабочее время».
Это говорит о том, что сбои систем, работающих круглосуточно, будут происходить в 3 раза чаще в нерабочее время, чем в рабочее время.
Очевидно, что есть много других соображений, которые могут помочь в этом; множественные смены, часы пик (которые для многих могут еще больше смещать сбои в нерабочее время) и т. д.
Да, мы находим его, и нет, это не случайность. Я уверен, что ваши серверы ненавидят вас. Я знаю, что мои серверы ненавидят меня, и, хотя они с радостью увидят меня мертвым, если они почувствуют, что теряют сознание, я уверен, что они продержатся, пока их демоны ntp не шепчут им в уши, что сейчас середина ночи, а сейчас хорошая время умирать. Они знают, что неудача в 10:30 испортит мне день, но неудача в 0345 испортит мне ночь, утащит меня в темноту в Лондон и испортит и следующий день. Им это нравится.
После того, как корпоративный брандмауэр вышел из строя в самый неудобный момент из-за неисправного жесткого диска, я отделил плату контроллера диска от жесткого диска, разрезал ее на четыре части, а затем носил - и все еще изнашиваю - четверть его платы, как скальп, свисающий с моей «цепочки офисов» (шнурок со всеми различными токенами доступа, которые я использую на всех своих сайтах). Я уверен, что вид этой ужасной реликвии в их глазах отныне в значительной степени удерживал ее братских и сестринских служителей, так что наказание за неудачу было ясно показано.
(На тот случай, если кто-то потерпит неудачу с чувством юмора, этот пост - шутка; за исключением того, что касается контроллера жесткого диска, что абсолютно верно и работает.)
Время между 23:00 и 6:00 кажется типичным временем для выполнения ночных заданий cron. Возможно, некоторые из них создают дополнительную нагрузку на ваши серверы, увеличивая риск отложенного сбоя, который может произойти именно тогда.
За ночь происходит большинство изменений инфраструктуры. Сети и другие ресурсы могут выйти из строя. Если вы используете удаленный мониторинг, вы увидите, что ваш сайт не работает, потому что он недоступен. Знание периодов обслуживания различных ресурсов поможет исключить эти простои из фактических.
Как отмечали другие, в среднем перебои в работе в нерабочее время более вероятны, если судить по часам. Учитывая доступность в будние дни и 8-часовой рабочий день, только 1/3 отключений должна происходить в рабочее время. Добавьте сюда выходные, и в рабочие дни будет еще меньше простоев.
Отслеживайте причины отключений и способы их обнаружения. Вы обнаружите, что некоторые сбои связаны с отключением таких ресурсов, как сеть. Они могут выглядеть как загадочные отключения, когда сайт пропадал на несколько минут и вернулся без вмешательства. Я ожидал, что многие из ваших ночных отключений связаны с изменениями инфраструктуры.
Изменения инфраструктуры обычно планируются, поэтому вы должны иметь возможность получать уведомления о них. Затем вы можете соответствующим образом скорректировать свой ответ. В вашем журнале отключений должно быть отражено, что отключение произошло из-за изменения. Также запишите любое вмешательство, которое требовалось. Вам может потребоваться добавить код восстановления в ваше приложение для обработки перезапусков базы данных или других подобных изменений ресурсов.
Знание окон обслуживания для различных ресурсов может помочь определить, какие ресурсы вызывают незапланированные простои. Возможно, вам потребуется отследить зависимости ваших ресурсов, поскольку сетевой диск и базы данных будут зависеть от сетевой инфраструктуры. Точно так же база данных может зависеть от сетевого дискового хранилища.
У меня умер сервер Voip за последние 3 месяца. «Умереть», возможно, не лучшее слово, поскольку после паники ядра машина станет загрузочной. Обычно машина безупречно работала с 7 утра до 7 вечера. Затем, через случайные промежутки времени, разделенные 1-30 днями, он закрывался и не отвечал на системную консоль, когда я возвращался в офис в 7 утра.
Примерно после 12 итераций этой ситуации ... что неизменно происходило между 23:00 и 7:00, было установлено, что вышла из строя материнская плата и, в частности, виноваты конденсаторы. Думаю, я где-то читал, что экстремальные температуры могут ускорить эту смерть. Я полагаю, что в моем маленьком офисе нет ничего необычного, но я обычно позволял температуре подниматься на 15 градусов по Фаренгейту и на 20 градусов ниже 75 градусов в нерабочее время. Итак, я считаю, что мелкие предприятия, в которых не используется охлажденный центр обработки данных, могут столкнуться с ошибками, вызванными температурой, в первые утренние часы.
Я снова помню, что журналы показывали сбой в течение 8 часов перед тем, как мы открыли наш магазин утром - всегда.