Этот пост я написала в рамках блогомарафона в ответ на тему “мой подконтрольный рабочий процесс на примере варки каши”. См. также https://t.me/WritingOnStickyNotes/88.
Иногда кашеварка останавливается: перестает греть, жалобно пищит и моргает.
Когда это случилось первый раз, было нервно. Что такое, почему, что делать, мы теперь останемся без каши?
Диагностики кашеварка не выдает, управление небогатое. Что делать – непонятно, поэтому сделали что могли: выключили кашеварку, вынули кастрюльку, подождали, установили кастрюльку обратно, включили. Помогло, кашеварка пошла работать.
А потом это случилось еще раз. И еще.
Со временем накопились кое-какие наблюдения. Кажется, влияет криво установленная кастрюлька, мокрое донышко и горячая вода для крупы. Гипотеза – кашеварка перегревается или термодатчик выдает неправильное измерение. Случается это раз в пару месяцев.
У нас есть способ вовремя узнавать о проблеме – жалобный писк кашеварки.
Есть процедура реагирования: выключить, вынуть кастрюльку, протереть донышко, аккуратно установить обратно, включить. Ну и включаем программу чуть заранее, чтобы был запас минут 10-15.
Отключения нечастые, и такой режим эксплуатации устраивает.
Если захочтеся более систематических решений, то можно собрать статистику по кастрюлькам – возможно, одна из них больше подвержена проблеме, и ее можно заменить. Или можно заменить кашеварку целиком.
И это напоминает мне одну проблему, с которой моя команда сталкивалась на протяжении года или двух.
Сервис, в котором я тогда работала, для хранения данных использовал MySQL, и моя команда занималась обеспечением его бесперебойной работы (mysql-ные DBA, так сказать).
Иногда запросы в базе начинали внезапно и ужасно тормозить, а сервис переставал отвечать.
Когда это случилось первый раз, было нервно. Что такое, почему, что делать, что теперь будет с базой и сервисом?
Что делать было не очень понятно, и сделали что могли: прибили все выполняющиеся запросы. Помогло, запросы пошли выполняться нормально, сервис поднялся.
А потом это случилось еще раз. И еще.
Со временем накопились наблюдения. Полного понимания не сложилось, но было видно, что в момент проблемы портились планы выполнения запросов к одной большой высоконагруженной таблице. Выглядело так, будто движок базы на секунду забывал про индекс в этой таблице, и запросы, запустившиеся в эту секунду, начинали выполняться вечность, блокировали таблицу, тормозили другие запросы, и вся работа вставала колом.
Происходило это примерно раз в пару кварталов.
У нас был способ узнавать, что проблема произошла. Даже два с половиной способа: мониторинги на торможение приложения, на load average сервера БД, и потом еще мониторинг “планы исполняющихся запросов совпадают с теоретическими планами” (его считаю за половинку, у него были особенности, это отдельная история).
Была процедура реагирования: зайти на проблемный сервер, запустить скрипт для сбора диагностики, потом прибить запросы. Записать происшествие в историю аварий.
Проблема приключалась нечасто, поэтому какое-то время такой режим устраивал. А потом мы вложились в аккуратное автоматическое прибивание зависших запросов, а еще в целом поуменьшили нагрузку на базу (оптимизировали некоторые тяжелые запросы), и проблема прекратила беспокоить. Вероятно, база продолжала иногда “терять” индексы, но работу сервиса целиком это больше не ломало.
Вот такая была история.
На что здесь хочется обратить внимание? Даже если систематическое решение недоступно или слишком дорого, можно сделать мониторинги и разработать процедуру реагирования, и это сделает жизнь легче – хоть с кашеваркой, хоть с базой данных.