Вы скажете - оксюморон! Позволю себе привести некоторые аргументы в защиту данного выражения.
Краткое вступление
Я часто занимаюсь поиском неисправностей в IT системах сложности от средней и выше. Ещё это иногда называют troubleshooting. Хотя иногда переходят на личности и даже обзывают бездельником. Перегрузи хост и дело сделано, говорят мне некоторые коллеги. Я поначалу удивлялся, как можно такое предложить, если на хосте крутится куча сервисов, иногда критических, если куча разработчиков родила массу процессов и хост является частью большой системы!? Потом перестал. И вот почему...
В IT сфере бушует индустриализация. Ничего плохого в этом нет и даже иногда это оправдано. Разделение труда, планирование и т.п. - отлично. Проблема в том, что индустриальная эпоха спровоцировала появление в IT большого количества узких специалистов, которые не имеют широгоко взгляда на задачу/систему, которую они разрабатывают или обслуживают. Они в этом не виноваты и обличать никого не собираюсь, все усилия направлены на поиск причины и решения проблемы. Я убеждён, что специалис должен иметь "широкий взгляд на мир" и на ряду с основной специализацией хотябы поверхносто понимать соседние области. Я называю таких allrounder или "мультинструменталистами" (муз. - играющими на разных инструменах)
Но давайте перейдём от макроэкономики и психологии к технике и я попытаюсь обосновать, почему не стоит просто ребутить сервера. Примем как аксиому, что система изначально работала хорошо и выполняла свои функции. Т.е. была в стабильном состоянии. Тут стоит уточнить и определить как минимум 3 возможных состояния системы:
стабильное (всё работает как надо)
метастабильное (работает, но по принципу "never touch a running system")
нестабильное (всё плохо)
Нормально работающие системы находятся либо в стабильном, либо на худой конец (и чаще всего) в метастабильном состояниях.
Продолжим. Потом что-то произошло и система перешла в нестабильное состояние. На этой стадии, обычно уже после пары-тройки ребутов, к вам приходят и просят посмотреть, что-ж там всё-таки не работает.
Здесь я введу ещё два важных термина. Состояния системы, как подмножество нестабильного:
стабильно нестабильное (или устойчиво нестабильное)
нестабильно нестабильное
Стабильно нестабильное или устойчиво нестабильное состояние системы
Самый важный момент. Мы точно знаем, что система работает не так, как надо, но не знаем почему. В этом состоянии у нас есть возможность посмотреть логи, поговорить с "людьми" (разрабами, прорабами, сетевиками и пользователями), накопить наблюдения для дальнейших суждений и выводов. Главное - не дестабилизировать стабильно нестабильную систему! Это мой слоган на данном этапе. Самый основной и любимый способ дестабилизации или другими словами, перевода системы в нестабильно нестабильное состояние - ребут.
Простой пример из жизни. Система работала со сбоями. После многочисленных ребутов проблема пропадала и мне ставили на вид, мол помогает, а ты нам тут сказки рассказываешь. Правда заодно появлялись странные артефакты в виде подвисания клиентских сессий и пропадания данных (иногда). Проблема спорадически появлялась снова с снова в самый неприятный момент, обычно на выходных. Оказалось, что накосячили с ротацией логов и диск переполнялся. При ребуте временный раздел освобождался и всё какое-то время как-то работало. Пока он снова не переполнялся. Мониторить этот раздел конечно забыли. Элементарно подправили алгоритм ротации логов. За 5 минут где-то. Есть масса более сложных случаев в больших системах с кучей серверов и сервисов, но не буду засорять эфир, смысл думаю понятен.
Нужно чётко понимать основную цель troubleshooting - определить источник вывода системы из равновесия и вернуть её в стабильное состояние. Часто же просходит неверная интерпретация. Многие боятся признаться в ошибке, а иногда даже пытаются её скрыть. Тут нужно добавить, что ответственные за систему тоже иногда пытаются найти или даже назначить виноватого. Это всё сильно вредит общему делу. Выходит, что без психологии в поиске неисправностей никак не обойтись. Что подтвержнает мой тезис о "мультиниструменталистах" во вступлении.
Подведём итоги. Для успехов в поиске и устранении неисправностей надо:
быть смелым и признаваться в своих ошибках. Это 50% успеха на пути к цели
удерживать нестабильную систему в стабильно нестабильном состоянии
искать неисправность
Всё, как в жизни :-)
Я "по верхам" (high level) пробежал по теории поиска неисправностей и высветил только её один аспект. Если будет интерес, могу углубиться в другие. Всем спасибо.
Win08
Возможность есть. А вот времени нет. Далеко не всегда есть время держать систему (прод) в нестабильном состоянии достаточно долго. Бизнес требует чтобы все работало, а разбираться будете потом. А в песочнице, увы, глюк/проблему воспроизвести не удается.
kipihs Автор
А долго обычно и не надо.
Мой опыт показывает, что в большинстве случаев таки есть возможность удержать достаточное время, если пользоваться постулатами troubleshooting.
Обычно правда ребутят или какие другие костыли подпирают, пока заказчик не начнёт конкретно наезжать.
На самом деле самый частый случай первый (непризнание ошибки).
Методы принимать комплексные: усилить мониторинг, логгирование, подумать о возможности репродуцирования ошибки на тестовой системе/песочнице и т.п.
Я только вскользь темы коснулся, она огромна. И в ней больше психологии, чем техники.