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

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

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

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

E51d363aa46f4d059d54a15e0bcd8e6f?s=128

Tech Talks @NSU

March 30, 2019
Tweet

Transcript

  1. 1.

    Семь раз отмерь, один раз отрежь или как "Production Ready

    Code" поможет спокойно спать по ночам Михаил Ярийчук Hibernating Rhinos
  2. 2.

    Немного обо мне Михаил Ярийчук  Программист .Net с 11

    летним опытом  В последние 6 лет разработчик СУБД RavenDB  Работаю над GraphAPI для RavenDB
  3. 3.
  4. 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
  5. 8.

    Ничто не ново под луною… В сложных (распределенных) системах 

    Неполадки и проблемы неизбежны  Неполадки не приводят к прекращению функциональности  Многослойная защита от неполадок  При катастрофических неполадках – множественные точки отказа  Cascading failures
  6. 12.

    Многослойная защита  Машина  Ремни безопасности  Подушки безопасности

     Индикатор нехватки топлива  ABS  Дорожная система  Жесткое разделение между полосами  Светофоры, дорожные знаки  Камеры слежения за движением  Дорожная Полиция
  7. 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)  И много чего еще
  8. 16.

    Ок, так что можно сделать насчет архитектуры?  При планировании

    быть “параноиком”  Модули (компоненты) должны предусматривать отказ всех остальных модулей (degraded mode functionality)  Fail-over, load balancing  Мониторинг, мониторинг и еще раз мониторинг  Стресс тесты, нагрузочные тесты→ на всю систему  Chaos Monkey
  9. 20.

    Жизнь после "deploy to production"...  Зависание?  Падение процесса?

    (crash)  Утечки памяти  Излишнее использование ресурсов  Паузы / медленная работа сервисов
  10. 21.

    Так что за зверь такой, этот "Production ready code"? 

    Архитектурные принципы  Принципы написания кода  Принципы проверки (QA)
  11. 22.

    Точки отказа "The only real answer here is do your

    homework and commit to solving implementation challenges with whatever tool you choose." Michael T. Nygard
  12. 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)
  13. 26.

    Точки отказа – что делать?  Ознакомится с API и

    библиотеками кода (3rd party + system)  RTFM!  Ограничения  Thread-safety  Возможные исключения (exceptions)  Что происходит во время "resource starvation" (high cpu, thread starvation)
  14. 29.
  15. 30.

    Circuit breaker  Повторные попытки при частых неполадках  Лишняя

    нагрузка? (repeated failure, thrashing)  Бесконечный цикл? HTTP Request/Response
  16. 32.

    Unbounded result set  Базы данных  Клиент/сервер  Любой

    API который возвращает данные  Тестовые данные VS Реальные данные
  17. 35.

    Изоляция компонентов  Проблемы одного модуля не должны влиять на

    остальные  Какие проблемы?  Resource starvation  Зависание  Infinite loop  Unhandled exceptions/AccessViolationException/StackOverflowException
  18. 37.

    Мониторинг  Встроенный/наружный  Реализация SNMP, WMI  Раннее оповещение

    + предотвращение проблем  Диагностика при возникновении проблем
  19. 39.
  20. 41.

    Пропускная способность, что может пойти не так?  Resource starvation

     Full queues timeouts  IO bottlenecks  Lock convoy!  Cascading failures!
  21. 42.

    Пропускная способность – например, рассмотрим Http Routing  ASP.NET built-in

    routing VS custom routing algorithm (Trie)  Complexity  Memory Allocations
  22. 43.

    Пропускная способность - что делать?  Сложность алгоритмов (Complexity) 

    Проверки пропускной способности алгоритмов  Нагрузочное тестирование, стресс-тестирование (load test vs stress test)  Мониторинг!  Приложение  Environment
  23. 44.

    Подытожим...  100% "Production-ready code" невозможен  Но можно подойти

    близко...  Точки отказа в коде - можно предусмотреть!  Следуя простым принципам можно (существенно) улучшить стабильность системы  Пропускная способность компонентов системы  Production-ready systems  Cascading failures  Здоровая паранойя
  24. 45.