Семь раз отмерь, один раз отрежь или как "Production Ready Code" поможет спокойно спать по ночам

Дизайн. Код. Баги. Тесты. Отладка. Сроки горят... Наконец-то работает, УРА! Продакшн. Проходит неделя.
Звонок в два часа ночи: Все пропало! Серверы полетели, спасай!

Знакомая история, да? Можно-ли предугатадь или даже предотвратить такой "ночной армагеддон"? Да!
В этом докладе я расскажу про принципы "Production-Ready Code", почему они важны и как их применять на практике.
Следуя этим простым принципам, в большинстве случаев можно предотвратить "ночные армагеддоны" и спать спокойно по ночам.

Transcript

1. Семь раз отмерь, один раз отрежь или как "Production Ready Code" поможет спокойно спать по ночам Михаил Ярийчук Hibernating Rhinos
2. Немного обо мне Михаил Ярийчук  Программист .Net с 11 летним опытом  В последние 6 лет разработчик СУБД RavenDB  Работаю над GraphAPI для RavenDB
4. "Production ready code"?
5. "Production ready code"? Not enough storage is available to process this command. at System.IO.__Error.WinIOError(Int32errorCode, String maybeFullPath) at System.IO.__ConsoleStream.Write(Byte[] buffer, Int32 offset, Int32 count) at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder) at System.IO.StreamWriter.Write(Char[] buffer, Int32 index, Int32 count) at System.IO.TextWriter.WriteLine(Stringvalue) at System.IO.TextWriter.SyncTextWriter.WriteLine(String value) at System.Console.WriteLine(Stringvalue) … остаток Stack Trace
6. "Production ready code"!
7. Архитектурный аспект Production-ready systems!
8. Ничто не ново под луною… В сложных (распределенных) системах  Неполадки и проблемы неизбежны  Неполадки не приводят к прекращению функциональности  Многослойная защита от неполадок  При катастрофических неполадках – множественные точки отказа  Cascading failures
9. Например, рассмотрим дорожно-транспортную систему Дороги, машины и все остальное...
10. Неполадки неизбежны... Дорожно-транспортные проишествия
11. Частичная функциональность... Degraded mode functionality
12. Многослойная защита  Машина  Ремни безопасности  Подушки безопасности  Индикатор нехватки топлива  ABS  Дорожная система  Жесткое разделение между полосами  Светофоры, дорожные знаки  Камеры слежения за движением  Дорожная Полиция
13. Многослойная защита  Предотвращение  Предупреждение
14. Каскадные неполадки (cascading failure) и множественные точки отказа (multiple points of failure)
15. Например, рассмотрим сервис Netflix Микросервисная архитектура  Webserver cluster (Frontend)  Billing system → Tax, Reporting, Payment Processor, API Service...  Service Bus  Database cluster (authentication, user records)  Streaming server cluster (videos!)  Caching cluster(s) (frontend, database, streaming)  И много чего еще
16. Ок, так что можно сделать насчет архитектуры?  При планировании быть “параноиком”  Модули (компоненты) должны предусматривать отказ всех остальных модулей (degraded mode functionality)  Fail-over, load balancing  Мониторинг, мониторинг и еще раз мониторинг  Стресс тесты, нагрузочные тесты→ на всю систему  Chaos Monkey
17. Ну а если о программировании?
18. Казалось бы, все ясно! Код Баги Тесты QA Продакшн
19. Поговорим о “последнем” этапе: Deploy to Production Работает и ладно...Deploy!
20. Жизнь после "deploy to production"...  Зависание?  Падение процесса? (crash)  Утечки памяти  Излишнее использование ресурсов  Паузы / медленная работа сервисов
21. Так что за зверь такой, этот "Production ready code"?  Архитектурные принципы  Принципы написания кода  Принципы проверки (QA)
22. Точки отказа "The only real answer here is do your homework and commit to solving implementation challenges with whatever tool you choose." Michael T. Nygard
23. Точки отказа? Клиент Сервер
24. Точки отказа  Unhandled exception (client, server)  Timeouts (http,database)  Временные сетевые проблемы - Exceptions!  Ограничения API, протоколов (too long url, too large request body...)  TCP accept queue full  Http queue full  Resource starvation -> timeout (client, http server)  DNS change → HttpClient caches DNS and it is static  Malformed/invalid data (format, shape, null)
25. Что еще более важно...
26. Точки отказа – что делать?  Ознакомится с API и библиотеками кода (3rd party + system)  RTFM!  Ограничения  Thread-safety  Возможные исключения (exceptions)  Что происходит во время "resource starvation" (high cpu, thread starvation)
27. Стабильность Кода "Hope is not a design method" Michael T. Nygard
28. Fail fast  Resource starvation  Hangs  Cascading failures
29. Fail fast
30. Circuit breaker  Повторные попытки при частых неполадках  Лишняя нагрузка? (repeated failure, thrashing)  Бесконечный цикл? HTTP Request/Response
31. Circuit breaker Ограничение повторных запросов
32. Unbounded result set  Базы данных  Клиент/сервер  Любой API который возвращает данные  Тестовые данные VS Реальные данные
33. Unbounded result set
34. Steady state
35. Изоляция компонентов  Проблемы одного модуля не должны влиять на остальные  Какие проблемы?  Resource starvation  Зависание  Infinite loop  Unhandled exceptions/AccessViolationException/StackOverflowException
36. Изоляция компонентов
37. Мониторинг  Встроенный/наружный  Реализация SNMP, WMI  Раннее оповещение + предотвращение проблем  Диагностика при возникновении проблем
38. Самодиагностика  Программа сама себя проверяет  Программа сама предпринимает шаги по исправлению
39. Capacity
40. Пропускная способность  Алгоритмы  Очереди (queues)  Thread pool  Клиент/сервер  Any IO (storage, network...)
41. Пропускная способность, что может пойти не так?  Resource starvation  Full queues timeouts  IO bottlenecks  Lock convoy!  Cascading failures!
42. Пропускная способность – например, рассмотрим Http Routing  ASP.NET built-in routing VS custom routing algorithm (Trie)  Complexity  Memory Allocations
43. Пропускная способность - что делать?  Сложность алгоритмов (Complexity)  Проверки пропускной способности алгоритмов  Нагрузочное тестирование, стресс-тестирование (load test vs stress test)  Мониторинг!  Приложение  Environment
44. Подытожим...  100% "Production-ready code" невозможен  Но можно подойти близко...  Точки отказа в коде - можно предусмотреть!  Следуя простым принципам можно (существенно) улучшить стабильность системы  Пропускная способность компонентов системы  Production-ready systems  Cascading failures  Здоровая паранойя
46. Вопросы? michael.yarichuk@hibernatingrhinos.com Вопросы? michael.yarichuk@hibernatingrhinos.com https://github.com/netflix/chaosmonkey https://www.amazon.com/Release-Design-Deploy- Production-Ready-Software-ebook/dp/B079YWMY2V https://github.com/ravendb