[Анализ и проектирование систем, Распределённые системы] Стабильная нестабильность — оксиморон или необходимость?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Вы скажете - оксиморон! Позволю себе привести некоторые аргументы в защиту данного выражения.Краткое вступлениеЯ часто занимаюсь поиском неисправностей в IT системах сложности от средней и выше. Ещё это иногда называют troubleshooting. Хотя иногда переходят на личности и даже обзывают бездельником. Перегрузи хост и дело сделано, говорят мне некоторые коллеги. Я поначалу удивлялся, как можно такое предложить, если на хосте крутится куча сервисов, иногда критических, если куча разработчиков родила массу процессов и хост является частью большой системы!? Потом перестал. И вот почему...
No RebootВ IT сфере бушует индустриализация. Ничего плохого в этом нет и даже иногда это оправдано. Разделение труда, планирование и т.п. - отлично. Проблема в том, что индустриальная эпоха спровоцировала появление в IT большого количества узких специалистов, которые не имеют широгоко взгляда на задачу/систему, которую они разрабатывают или обслуживают. Они в этом не виноваты и обличать никого не собираюсь, все усилия направлены на поиск причины и решения проблемы. Я убеждён, что специалис должен иметь "широкий взгляд на мир" и на ряду с основной специализацией хотябы поверхносто понимать соседние области. Я называю таких allrounder или "мультинструменталистами" (муз. - играющими на разных инструменах)Но давайте перейдём от макроэкономики и психологии к технике и я попытаюсь обосновать, почему не стоит просто ребутить сервера. Примем как аксиому, что система изначально работала хорошо и выполняла свои функции. Т.е. была в стабильном состоянии. Тут стоит уточнить и определить как минимум 3 возможных состояния системы:
- стабильное (всё работает как надо)
- метастабильное (работает, но по принципу "never touch a running system")
- нестабильное (всё плохо)
Нормально работающие системы находятся либо в стабильном, либо на худой конец (и чаще всего) в метастабильном состояниях. Продолжим. Потом что-то произошло и система перешла в нестабильное состояние. На этой стадии, обычно уже после пары-тройки ребутов, к вам приходят и просят посмотреть, что-ж там всё-таки не работает.Здесь я введу ещё два важных термина. Состояния системы, как подмножество нестабильного:
- стабильно нестабильное (или устойчиво нестабильное)
- нестабильно нестабильное
Стабильно нестабильное или устойчиво нестабильное состояние системыСамый важный момент. Мы точно знаем, что система работает не так, как надо, но не знаем почему. В этом состоянии у нас есть возможность посмотреть логи, поговорить с "людьми" (разрабами, прорабами, сетевиками и пользователями), накопить наблюдения для дальнейших суждений и выводов. Главное - не дестабилизировать стабильно нестабильную систему! Это мой слоган на данном этапе. Самый основной и любимый способ дестабилизации или другими словами, перевода системы в нестабильно нестабильное состояние - ребут.Простой пример из жизни. Система работала со сбоями. После многочисленных ребутов проблема пропадала и мне ставили на вид, мол помогает, а ты нам тут сказки рассказываешь. Правда заодно появлялись странные артефакты в виде подвисания клиентских сессий и пропадания данных (иногда). Проблема спорадически появлялась снова с снова в самый неприятный момент, обычно на выходных. Оказалось, что накосячили с ротацией логов и диск переполнялся. При ребуте временный раздел освобождался и всё какое-то время как-то работало. Пока он снова не переполнялся. Мониторить этот раздел конечно забыли. Элементарно подправили алгоритм ротации логов. За 5 минут где-то. Есть масса более сложных случаев в больших системах с кучей серверов и сервисов, но не буду засорять эфир, смысл думаю понятен. Нужно чётко понимать основную цель troubleshooting - определить источник вывода системы из равновесия и вернуть её в стабильное состояние. Часто же просходит неверная интерпретация. Многие боятся признаться в ошибке, а иногда даже пытаются её скрыть. Тут нужно добавить, что ответственные за систему тоже иногда пытаются найти или даже назначить виноватого. Это всё сильно вредит общему делу. Выходит, что без психологии в поиске неисправностей никак не обойтись. Что подтвержнает мой тезис о "мультиниструменталистах" во вступлении.Подведём итоги. Для успехов в поиске и устранении неисправностей надо:
- быть смелым и признаваться в своих ошибках. Это 50% успеха на пути к цели
- удерживать нестабильную систему в стабильно нестабильном состоянии
- искать неисправность
Всё, как в жизни :-)Я "по верхам" (high level) пробежал по теории поиска неисправностей и высветил только её один аспект. Если будет интерес, могу углубиться в другие. Всем спасибо.
===========
Источник:
habr.com
===========
Похожие новости:
- [Анализ и проектирование систем, Управление проектами, Инженерные системы] Архитектура архитектуры. Шаг 5: один за всех и все на одного
- [Информационная безопасность, Криптография, Анализ и проектирование систем, Хранение данных] Элементарная гигиена и слив базы сторонников Навального
- [Тестирование веб-сервисов, Kotlin, Gradle, Распределённые системы, Микросервисы] Использование Spring Cloud Stream Binding с брокером сообщений Kafka
- [Анализ и проектирование систем, Работа с 3D-графикой, CAD/CAM] Двумерная САПР DraftSight удачно дополняет системы 3D-моделирования
- [Анализ и проектирование систем, Управление разработкой] Low-code с точки зрения разработчиков — есть ли плюсы для инженеров?
- [Облачные вычисления, Разработка под Linux, Распределённые системы, Процессоры] Сравнение криптографической производительности популярных ARM-процессоров для DYI и Edge-устройств, плюс Xeon E-2224
- [Анализ и проектирование систем, IT-инфраструктура, Проектирование и рефакторинг, Usability, Data Engineering] RPA — обезболивающее или серебряная пуля?
- [Анализ и проектирование систем, Erlang/OTP, Параллельное программирование, Elixir/Phoenix] To spawn, or not to spawn? (перевод)
- [Анализ и проектирование систем, Управление проектами, Инженерные системы] Архитектура архитектуры: воспалённый аппендикс
- [Анализ и проектирование систем, Карьера в IT-индустрии] – А у нас нет мышей! – А мы заведём… Какая польза от архитектора решений
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_raspredelennye_sistemy (Распределённые системы), #_stabilnost (стабильность), #_nestabilnost_raboty (нестабильность работы), #_metastabilnost (метастабильность), #_reboot, #_troubleshooting, #_poisk_neispravnostej (поиск неисправностей), #_peregruzka_servera (перегрузка сервера), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_raspredelennye_sistemy (
Распределённые системы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 09:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Вы скажете - оксиморон! Позволю себе привести некоторые аргументы в защиту данного выражения.Краткое вступлениеЯ часто занимаюсь поиском неисправностей в IT системах сложности от средней и выше. Ещё это иногда называют troubleshooting. Хотя иногда переходят на личности и даже обзывают бездельником. Перегрузи хост и дело сделано, говорят мне некоторые коллеги. Я поначалу удивлялся, как можно такое предложить, если на хосте крутится куча сервисов, иногда критических, если куча разработчиков родила массу процессов и хост является частью большой системы!? Потом перестал. И вот почему...  No RebootВ IT сфере бушует индустриализация. Ничего плохого в этом нет и даже иногда это оправдано. Разделение труда, планирование и т.п. - отлично. Проблема в том, что индустриальная эпоха спровоцировала появление в IT большого количества узких специалистов, которые не имеют широгоко взгляда на задачу/систему, которую они разрабатывают или обслуживают. Они в этом не виноваты и обличать никого не собираюсь, все усилия направлены на поиск причины и решения проблемы. Я убеждён, что специалис должен иметь "широкий взгляд на мир" и на ряду с основной специализацией хотябы поверхносто понимать соседние области. Я называю таких allrounder или "мультинструменталистами" (муз. - играющими на разных инструменах)Но давайте перейдём от макроэкономики и психологии к технике и я попытаюсь обосновать, почему не стоит просто ребутить сервера. Примем как аксиому, что система изначально работала хорошо и выполняла свои функции. Т.е. была в стабильном состоянии. Тут стоит уточнить и определить как минимум 3 возможных состояния системы:
 Нормально работающие системы находятся либо в стабильном, либо на худой конец (и чаще всего) в метастабильном состояниях. Продолжим. Потом что-то произошло и система перешла в нестабильное состояние. На этой стадии, обычно уже после пары-тройки ребутов, к вам приходят и просят посмотреть, что-ж там всё-таки не работает.Здесь я введу ещё два важных термина. Состояния системы, как подмножество нестабильного:
=========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_raspredelennye_sistemy ( Распределённые системы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 09:09
Часовой пояс: UTC + 5