Русский
Русский
English
Статистика
Реклама

Стабильная нестабильность оксиморон или необходимость?

Вы скажете - оксиморон! Позволю себе привести некоторые аргументы в защиту данного выражения.

Краткое вступление

Я часто занимаюсь поиском неисправностей в IT системах сложности от средней и выше. Ещё это иногда называют troubleshooting. Хотя иногда переходят на личности и даже обзывают бездельником. Перегрузи хост и дело сделано, говорят мне некоторые коллеги. Я поначалу удивлялся, как можно такое предложить, если на хосте крутится куча сервисов, иногда критических, если куча разработчиков родила массу процессов и хост является частью большой системы!? Потом перестал. И вот почему...

No RebootNo Reboot

В IT сфере бушует индустриализация. Ничего плохого в этом нет и даже иногда это оправдано. Разделение труда, планирование и т.п. - отлично. Проблема в том, что индустриальная эпоха спровоцировала появление в IT большого количества узких специалистов, которые не имеют широгоко взгляда на задачу/систему, которую они разрабатывают или обслуживают. Они в этом не виноваты и обличать никого не собираюсь, все усилия направлены на поиск причины и решения проблемы. Я убеждён, что специалис должен иметь "широкий взгляд на мир" и на ряду с основной специализацией хотябы поверхносто понимать соседние области. Я называю таких allrounder или "мультинструменталистами" (муз. - играющими на разных инструменах)

Но давайте перейдём от макроэкономики и психологии к технике и я попытаюсь обосновать, почему не стоит просто ребутить сервера. Примем как аксиому, что система изначально работала хорошо и выполняла свои функции. Т.е. была в стабильном состоянии. Тут стоит уточнить и определить как минимум 3 возможных состояния системы:

  • стабильное (всё работает как надо)

  • метастабильное (работает, но по принципу "never touch a running system")

  • нестабильное (всё плохо)

Нормально работающие системы находятся либо в стабильном, либо на худой конец (и чаще всего) в метастабильном состояниях.

Продолжим. Потом что-то произошло и система перешла в нестабильное состояние. На этой стадии, обычно уже после пары-тройки ребутов, к вам приходят и просят посмотреть, что-ж там всё-таки не работает.

Здесь я введу ещё два важных термина. Состояния системы, как подмножество нестабильного:

  • стабильно нестабильное (или устойчиво нестабильное)

  • нестабильно нестабильное

Стабильно нестабильное или устойчиво нестабильное состояние системы

Самый важный момент. Мы точно знаем, что система работает не так, как надо, но не знаем почему. В этом состоянии у нас есть возможность посмотреть логи, поговорить с "людьми" (разрабами, прорабами, сетевиками и пользователями), накопить наблюдения для дальнейших суждений и выводов. Главное - не дестабилизировать стабильно нестабильную систему! Это мой слоган на данном этапе. Самый основной и любимый способ дестабилизации или другими словами, перевода системы в нестабильно нестабильное состояние - ребут.

Простой пример из жизни. Система работала со сбоями. После многочисленных ребутов проблема пропадала и мне ставили на вид, мол помогает, а ты нам тут сказки рассказываешь. Правда заодно появлялись странные артефакты в виде подвисания клиентских сессий и пропадания данных (иногда). Проблема спорадически появлялась снова с снова в самый неприятный момент, обычно на выходных. Оказалось, что накосячили с ротацией логов и диск переполнялся. При ребуте временный раздел освобождался и всё какое-то время как-то работало. Пока он снова не переполнялся. Мониторить этот раздел конечно забыли. Элементарно подправили алгоритм ротации логов. За 5 минут где-то. Есть масса более сложных случаев в больших системах с кучей серверов и сервисов, но не буду засорять эфир, смысл думаю понятен.

Нужно чётко понимать основную цель troubleshooting - определить источник вывода системы из равновесия и вернуть её в стабильное состояние. Часто же просходит неверная интерпретация. Многие боятся признаться в ошибке, а иногда даже пытаются её скрыть. Тут нужно добавить, что ответственные за систему тоже иногда пытаются найти или даже назначить виноватого. Это всё сильно вредит общему делу. Выходит, что без психологии в поиске неисправностей никак не обойтись. Что подтвержнает мой тезис о "мультиниструменталистах" во вступлении.

Подведём итоги. Для успехов в поиске неисправностей надо:

  • быть смелым и признаваться в своих ошибках. Это 50% успеха на пути к цели

  • удерживать нестабильную систему в стабильно нестабильном состоянии

  • искать неисправность

Всё, как в жизни :-)

Я "по верхам" (high level) пробежал по теории поиска неисправностей и высветил только её один аспект. Если будет интерес, могу углубиться в другие. Всем спасибо.

Источник: habr.com
К списку статей
Опубликовано: 19.04.2021 12:12:03
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Анализ и проектирование систем

Распределенные системы

Стабильность

Нестабильность работы

Метастабильность

Reboot

Troubleshooting

Поиск неисправностей

Перегрузка сервера

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru