2. Немного о себе
Антон Наумович
Более 10 лет опыта в разработке
● C++ тимлид и архитектор в IASO Backup
● Консультант в DPI Solutions
● В прошлом – разработчик в Microsoft, команда
Hyper-V (Windows Server 2008 R2/2012)
Специализируюсь в архитектуре, производительности,
отладке, техническом troubleshooting-е
3. О чем поговорим?
1. О качестве приложений с технической, а не
функциональной точки зрения
2. О построении автоматической системы
отслеживания “технического” качества
3. О максимально возможном дистанцировании
человека от построенной системы
В контексте нативных и .Net приложений под Windows
7. Дампы памяти!
1. Дамп – файл-слепок памяти процесса, который
можно снять в любой момент:
● при падении процесса
● с зависшего процесса
● с работающего процесса
2. Беглого анализа обычно достаточно чтобы понять
причину проблемы
3. Сам факт наличия дампа – уже сигнал “внимание,
что-то произошло”
8. Сбор дампов
Нужен сторонний процесс-контроллер для
независимости наблюдений
Также умеют снимать:
- Task Manager
- Process Explorer и
procdump (Sysinternals)
9. Что умеет отслеживать
procdump?
Много чего:
● Падения (-t -e)
● Потребление процессора (-c)
● Потребление памяти (-m)
● Зависшие окна (-h)
● Выход за пределы любых performance counters –
очень мощная вещь (-p)
10. Что еще умеет procdump?
● Ожидать старта процесса (-w)
● Писать дампы сериями (-n)
● Работать с таймаутами (-s)
● Делать полные дампы с минимальным
вмешательством в процесс (-r)
● Конфигурировать имена и расположение дампов
12. Как извлечь информацию?
Анализ дампа – то же
самое, что и отладка,
только в статике
Можно и автоматически:
cdb.exe -y C:lab -i C:lab -z C:labSuperApp.dmp -c "~*k;q" > C:analysis.txt
13. Что в результате анализа?
Обычно достаточно стеков потоков чтобы найти причину проблемы
008afcf0 MSVCP120!std::_Xout_of_range+0x36
008fc86b SuperApp!WorkerProcessor::GetNextChunk+0x1e1
0061d914 SuperApp!WorkerProcessor::CalculateAverage+0x202
0062875c SuperApp!WorkerModule::ProcessQueueEvent+0xdf
0012877a SuperApp!WorkerModule::TakeSingleItem+0x373
004dc89a SuperApp!WorkerModule::Run+0x67
00bdc100 SuperApp!main+0x1955
15. Существующие похожие решения
Windows Error Reporting
http://msdn.microsoft.com/en-
us/library/windows/desktop/bb513641(v=vs.85).aspx
Mozilla Crash Reporter
https://support.mozilla.org/en-US/kb/mozillacrashreporter
16. Символ-сервер
- Используется для хранения и быстрого доступа к
отладочной информации
- На символ-сервер выкладываются все отладочные
файлы предназначенные для анализа
- Значительно ускоряет отладку – не нужно искать
файлы вручную
17. Синие экраны смерти
При “падении” Windows пишется дамп системы в файл
C:WindowsMemory.dmp
Анализ тривиален:
1. Открываем дамп-файл в отладчике WinDbg или cdb
2. Указываем адрес Microsoft символ-сервера -
http://msdl.microsoft.com/download/symbols
3. Выполняем одну команду “analyze -v”
18. Инструментарий
• Набор отладчиков Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx
• Семейство утилит Sysinternals
http://technet.microsoft.com/en-us/sysinternals/bb545021.aspx
• Библиотека Google Breakpad
https://code.google.com/p/google-breakpad/
• Windows API: семейство Debug Help
http://msdn.microsoft.com/en-
us/library/windows/desktop/ms679309(v=vs.85).aspx
• Microsoft Symbols Server
http://en.wikipedia.org/wiki/Microsoft_Symbol_Server
19. 1. Ускоряем нахождение и устранение
дефектов
2. Максимально автоматизируем и исключаем
человека из цепочки
3. Даем возможность мгновенно среагировать
на критическую проблему
4. Отслеживаем показатели качества от версии
к версии
5. Повышаем надежность программы
Какая выгода?
Я расскажу о контроле качества в реальном времени - то есть не в “лабораторных” условиях, а во время того, как приложение выполняет свою реальную работу на машинах конечных пользователей.
Фактически, речь пойдет о построении системы обратной связи из продакшена в “Центр Управления Полетами” :)
Такая система находится в сфере интересов и на стыке компетенции многих отделов - Development, QA+Automation, Support
Я отвечаю за разработку серверной части бэкап-системы в компании IASO Backup
Работаю консультантом в DPI.Solutions
2 года проработал в компании Microsoft, в команде Hyper-V, которая является частью подразделения Windows
Раньше было модно язвительно отзывать о Windows в плане качества, однако неудача с Windows Vista, года пришлось просто “потерять” результаты годовой работу тысяч человек, многому научила руководство.
Сейчас там очень серьезные подходы к качеству, в том числе благодаря развитию автоматизированного тестирования - соотношение разработчиков и автоматизаторов в Windows - примерно 1:1
В мире совсем немного софта, который успешно работает на сотнях миллионов различных компьютеров, и стоит присмотреться к подходам к качеству, которые используются в его разработке.
Понятие качества в моем докладе рассматривается с чисто “технической” точки зрения - то есть фактически это понятие о том, насколько рационально приложение использует ресурсы компьютера, не касаясь того, насколько оно корректно с функциональной стороны.
Мы поговрим, как строится автоматическая система мониторинга и обратной связи, в которой человек выступает только как эксперт на самой финальной стадии.
Предлагаемое решение в основном релевантно для нативных приложений и .Net
Нас будут интересовать такие показатели качества как:
падения (выполнение недопустимой операции) - все видели такое окошечко, скоро мы узнаем что происходит за кулисами когда мы соглашаемся отправить отчет
подвисания - когда приложение перестает отвечать на внешние раздражители
потребление памяти - либо утечки, либо просто нерациональное ее использование
потребление процессора
и дугие - специфические для предметной области, или комбинированные перечисленные выше.
Причина как правило в 90% случаев - это человеческий фактор, т.е. ошибки разработчиков. Мы все люди, мы все делаем ошибки, и будем их делать.
Нюансы сторонних библиотек и разнообразие окружения - это зачастую тоже человеческий ошибки, только других людей.
Что же нам поможет разобраться в причинах “неправильного” поведения?
Причем нам, людям, желательно сидеть перед Центром Управления Полетами и наблюдать, можно сильно задумавшись, реагируя на форс-мажоры, а не лезть засуча рукава в работающий ядерный реактор :)
В Windows, как и в других операционных системах, есть встроенная возможность снимать с процесса слепок памяти в любой момент времени
Причем беглого анализа достаточно чтобы найти причину того или иного отклонения
Более того, очень важно, параметры отклонений можно подобрать так, что сам факт наличия дампа - уже сигнал “Внимание”
Поговорим о том, как же снимать дампы
В докладе приводится сквозной пример - приложение SuperApp.
Обычно если приложение должно работать в фоне, то в связке с ним идет и приложение-контроллер SuperController, который отвечает за то чтобы его подопечный жил и функционировал.
Так вот, это приложение-контроллер можно нагрузить дополнительной работой и заставить мониторить важные показатели жизнедеятельности реального работника, и в случае отклонений этих показателей от нормы снимать дамп с наблюдаемого.
Также, дампы умеют снимать Task Manager (встроенный в Windows) и очень мощная утилита procdump из sysinternals - на ней мы остановимся подробнее для демонстрации спектра возможностей.
В качестве примеров Performance Counter - ов можно привести количество открытых файлов, количество прочитанных с диска или отосланных в сеть байт, и так далее.
Фактически, обвешимаем приложение-работник “инспекторами” и следим, чтобы приложение находилось в заданном “коридоре качества”.
Как только происходит отклонение - мгновенно получаем об этом нотификацию фактом наличия дампа.
Немного технических деталей об анализе дампов.
Для анализа нужны три компонента - отладочная информация, исполняемый файл и отладочные символы
Анализ - это очень просто, то же самое что и отладка, то есть любой программист априори умеет это делать
Это элементарно автоматизируемо, например с помощью отладчика cdb
Пример - проблема обычно кроется в самых последних фреймах - вот выход за границы вектора
Мы знаем как собирать и как анализировать дампы - если связать все вместе, получится такая картина.
На клиенте
На клиентской стороне SuperApp и SuperController работают в паре - SuperApp делает свою работу, SuperController следит за ним
Как только происходит отклонение - SuperController снимает дамп и отсылает его на сервер (например, по протоколу FTP или HTTP) вместе со вспомогательной информацией.
На сервере
Присланный дамп попадает в хранилище, например на файловой системе или в базе данных
В фоне процесс-аналитик SuperAnalyst запускает анализ дампов, извлекая нужную эксперту информацию
О самых критичных проблемах процесс-аналитик сообщает эксперту например через почту или SMS. Иногда надо среагировать мгновенно.
Любое более-менее серьезное приложение имеет похожую систему обратной связи - например Windows, Mozilla и т.п.
Технология для облегчения доступа к отладочной информации разных версий. Не нужно тратить время на поиск символов, достаточно просто указать один адрес, остальное сделает отладчик.
С помощью бесплатных Debugging Tools for Windows и SysInternals можно организовать подобную систему в тестовой лаборатории - причем за считанные дни, причем практически без дополнительных усилий со стороны программистов.