Приветствую!

Собственно сабж.
Я был на докладе посвященном manageability, вдохновился им, но информации в инете как-то не много. Нашел блог http://blogs.msdn.com/b/manageability_aint_easy/, но он уже давно не обновляется.

Чего хочется:
— В перспективе хочу чтобы время восстановления после сбоев системы было минимальным, в идеале система могла сама себя лечить.
— Конкретно сейчас хочется понять делают ли такое и как. А то может и не нужно такое?

В блоге есть фраза с которой я полностью согласен, но пока не знаю как реализовать такой подход "Every second spent diagnosing a problem is a waste of time".

12/15/2013 11:12 PM, Аноним 853 пишет:

> Чего хочется:
> — В перспективе хочу чтобы время восстановления после сбоев системы было
> минимальным, в идеале система могла сама себя лечить.
> — Конкретно сейчас хочется понять делают ли такое и как. А то может и не
> нужно такое?
Все зависит от размера твоего кошелька и затраченного времени.

Здравствуйте, Vzhyk, Вы писали:

>> — Конкретно сейчас хочется понять делают ли такое и как. А то может и не
>> нужно такое?
V>Все зависит от размера твоего кошелька и затраченного времени.

Какой-то фиговый кэп у тебя получился. Вот так надо:

Проблема не столько в кошельке/времени, сколько в конкретных требованиях к системе. Обеспечение заданного sla — это комплексное мероприятие, которое (в идеале) затрагивает всё, от разработки-тестирования и до процедуры отбора поставщиков. Определитесь от каких угроз и какими ресурсами вы готовы защищаться, дальше уже можно будет обсуждать конкретику.

Если речь про коробочный софт, то время восстановления как правило сводится к восстановлению из бэкапа, или, в лучшем случае, к горячему перекидыванию клиентов на заранее подготовленное зеркало. В любом из вариантов проблема не столько техническая, сколько управленческая.

Если речь про сложные (штучные) системы, то вопрос несколько странный, подобные вещи должны рассматриваться на самых ранних этапах разработки, вместе с определением прочих базовых требований.

12/16/2013 12:34 PM, Sinix пишет:

> Какой-то фиговый кэп у тебя получился. Вот так надо:
На столько много буковок ни о чем у меня настроения нет. А так кратко,
точно и не нужно.

12/16/2013 12:34 PM, Sinix пишет:

> Проблема не столько в кошельке/времени, сколько в конкретных требованиях
> к системе. Обеспечение заданного sla — это комплексное мероприятие,
> которое (в идеале) затрагивает всё, от разработки-тестирования и до
> процедуры отбора поставщиков. Определитесь от каких угроз и какими
> ресурсами вы готовы защищаться, дальше уже можно будет обсуждать конкретику.
Во-во. А выше вопрос был про сфероконя.

Здравствуйте, Sinix, Вы писали:

Спасибо за ответ!

S>Если речь про сложные (штучные) системы, то вопрос несколько странный, подобные вещи должны рассматриваться на самых ранних этапах разработки, вместе с определением прочих базовых требований.
Речь про штучную систему. Как раз рассматриваю подобные вещи на самом раннем этапе разработки.
Система распределённая, технологии Win/.Net, в качестве платформы мониторинга может быть будет SCOM, пока решаем.

S>Проблема не столько в кошельке/времени, сколько в конкретных требованиях к системе. Обеспечение заданного sla — это комплексное мероприятие, которое (в идеале) затрагивает всё, от разработки-тестирования и до процедуры отбора поставщиков. Определитесь от каких угроз и какими ресурсами вы готовы защищаться, дальше уже можно будет обсуждать конкретику.
Я хочу чтобы операторы на поддержке не разбирались в calstack'ах, а сразу понимали что чинить. Стал смотреть что есть, какие техники есть чтобы удешевить поддержку системы и её простой в случае сбоев. Обнаружил целую область, о которой даже не слышал. Вот и решил испросить у коллег, может есть какие паттерны, чтобы не набивать себе шишки.

Вот пример, система клиентам стала отдавать ошибки при обращении к одному из REST-сервисов, при этом сам по себе endpoint мониторится, мониторинг зёлёный, но от клиентов пошли жалобы. Т.е. получается, что нужно мониторить внутреннее состояние. Добавлю performance counter для подсчёта ошибок + сервис анализирующий этот самый performance counter. Как сервис видит, что ошибки полезли, так сразу загорался бы красный мониторинг. Операторы начинают анализировать логи, там что-то непонятное про timeout при каких-то http вызовах. Ок, добавляем диагностики в обращения ко всем внешним системам, обрабатываем исключения, в итоге оператор видит, что при подключении к ya.ru (например) возникает ошибка connect timeout. Что делать не понятно, звонят разработчикам. Дописываем в KB, что в случае connect timeout возможными причинами являются изменения на firewall'е, если таковые недавно проводились. И в таком духе.
Но это всё итерационный подход, сейчас же хочу сразу при проектировании заложить точки отказа и что делать в случае отказов. Нужно понять в каком виде осуществлять все эти мониторинги, нужно понять в каком виде описывать.

Ещё же можно накапливать статистику и мониторить её, например:

Тут стрелочками показаны падения, причем не в нашей системе, а у провайдера. Если бы был мониторинг который анализирует такие провалы, то быстро бы обнаружилась проблема. Может есть какие-то решения для подобного анализа?

Здравствуйте, Аноним, Вы писали:

S>>Проблема не столько в кошельке/времени, сколько в конкретных требованиях к системе. Обеспечение заданного sla — это комплексное мероприятие, которое (в идеале) затрагивает всё, от разработки-тестирования и до процедуры отбора поставщиков. Определитесь от каких угроз и какими ресурсами вы готовы защищаться, дальше уже можно будет обсуждать конкретику.
А>Я хочу чтобы операторы на поддержке не разбирались в calstack'ах, а сразу понимали что чинить. Стал смотреть что есть, какие техники есть чтобы удешевить поддержку системы и её простой в случае сбоев. Обнаружил целую область, о которой даже не слышал. Вот и решил испросить у коллег, может есть какие паттерны, чтобы не набивать себе шишки.

А, тогда единственный рабочий способ — отключаемая трассировка + ассерты в коде.

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

Если нужен автоматизированный анализ по логу — нужно писать лог в xml-виде, с фиксированной схемой и вложенностью операций, чтобы параллельные действия не накладывались друг на друга. Как пример:

<Op Text="123" Time="..." Stack="...">
 <Op Text="123\1234" Time="..." Stack="...">
   <Info>...</Info>
   <OpCompleted Time="..." />
 </Op>
 <OpCompleted Time="..." />
</Op>

В коде будет выглядеть как-то так

Автор: Sinix
Дата: 22.11.13

.

Что важно — время должно быть в UTC, для диагностик проблем производительности нужно указывать в логе время до миллисекунд + саму запись в лог выполнять в фоновом потоке.

А>Ок, добавляем диагностики в обращения ко всем внешним системам, обрабатываем исключения, в итоге оператор видит, что при подключении к ya.ru (например) возникает ошибка connect timeout. Что делать не понятно, звонят разработчикам. Дописываем в KB, что в случае connect timeout возможными причинами являются изменения на firewall'е, если таковые недавно проводились. И в таком духе.
При наличии лога примитивные правила диагностики можно добавлять вручную, например, черей xslt/xquery. Хотя на мой взгляд, правильное решение — не диагностировать ошибки по логу, а сразу заводить тикет на починку и исправлять. Выгоднее получается.

А>Но это всё итерационный подход, сейчас же хочу сразу при проектировании заложить точки отказа и что делать в случае отказов. Нужно понять в каком виде осуществлять все эти мониторинги, нужно понять в каком виде описывать.
Это делается ещё проще: все те же отключаемые ассерты в коде, в ассерт прописываем уникальный id, по id перенаправляем на страницу поддержки.

А>Ещё же можно накапливать статистику и мониторить её... Если бы был мониторинг который анализирует такие провалы, то быстро бы обнаружилась проблема. Может есть какие-то решения для подобного анализа?
Всё тот же анализ по xml-логу. В первую очередь важна возможность собрать машиночитаемые данные, обработка — это уже дело десятое.