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