Comments 4
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
Ваш юмор оправдан в случае маленького предприятия, когда количество информационных и инженерных систем с в районе тысячи, когда админы работают, как на конвейере, тогда становится не смешно.
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Если вы обратите внимание, то предлагаемые вами решения учтены в схеме — они являются обходным решение, пока отсутствуют ресурсы.
Если вы будете внимательны, то увидите, что в данном кейсе рассматривается ситуация, когда система внедряется без проектных виртуальных мощностей. В этом случае может быть так, что самый опытный DBA будет способен лишь снизить стоимость корневой причины, но не устранить её. И вендоры часто беспомощны.
Практики управления проблемами. Недопоставка виртуальных мощностей