Поуки от 15 години инциденти в продукция

Запис: https://www.youtube.com/watch?v=_ms0aQscrgk&list=PLX-Eu7bfT8M_MRzsoi9BWIwXuYegGnykT&index=6

Като ръководител на инфраструктурния екип в Dext, чувствам, че нося лична отговорност както за бързото разрешаване на всеки инцидент в продукция, така и за тяхното предотвратяване (ха-ха, невъзможно). Бил съм на първа линия по време на много инциденти и това ме е научило на много. Ще ви споделя няколко по-интересни и запомнящи се инцидента или проблема от реална продукционна среда и ще ви споделя какви изводи съм си направил от тях. Освен самите случки, които, надявам се, ще бъдат забавни за странична аудитория, "поуките" ще се въртят около какви инструменти за метрики, аларми и дебъгване са ни били особено полезни, какъв процес следваме по време на инцидент и как това ни помага (или пречи), включително и как комуникираме и ескалираме. Ще засегна и някои моменти около устойчиви софтуерни архитектури и размисли около пускане на по-рискови промени в продукция.

Transcript

2. Поуки от 15 години инциденти в продукция Димитър Димитров
3. 15* години челен опит с мотиката Димитър Димитров
4. Какво да очаквате 1. Малко философстване по темата 2. Мисли на други, по-умни от мен 3. Разкази на очевидец от окопите 4. Изводи, съвети, предложения 5. Да не ми стигне времето
5. • Да научим нещо заедно • Идеи как да избегнете сходни мотики • Или, поне да се позабавлявате на чужд гръб • Да се вместя в 30 минути KPI – поне 3 въпроса, които да ме изпотят 😅 Основните ми цели днес
6. 1. Философстване
7. “To err is human.”
8. Всяка грешка е възможност за развитие. Прогресираме, като се учим от грешките си. Ако не грешим, най-вероятно сме спрели. To err is human.
9. Още по-добре 😄 • https://github.com/danluu/post-mortems – интересна и богата колекция от различни инциденти на предимно софтуерни компании. • https://k8s.af/ – Kubernetes Failure Stories. Да се учим от грешките на другите!
10. • Полезно е да се говори по темата • Не е зле да имате incident response процес • Който е blame-free и фокусиран над фактите • И да оставяте писмена следа за случката и поуките • А ако от време на време тренирате incident response, ще сте 🥇 На практика:
11. 2. Мъдри мисли
12. “Complex systems contain changing mixtures of failures latent within them.” Richard I. Cook, MD
13. Richard I. Cook, MD “Complex systems run in degraded mode. [They] run as broken systems.”
14. “Catastrophe is always just around the corner.” Richard I. Cook, MD
15. Richard I. Cook, MD “[...] accident reviews nearly always note that the system has a history of prior ‘proto-accidents’ that nearly generated catastrophe.”
16. Richard I. Cook, MD “Catastrophe requires multiple failures – single point failures are not enough.”
17. Richard I. Cook, MD “Failure free operations require experience with failure.”
18. • От Richard I. Cook, MD • Труд от 1998-2000 г. • https://how.complexsystems.fail/ How Complex Systems Fail
19. “TTR is more important than TBF (for most types of F)” John Allspaw, former CTO @ Etsy https://www.kitchensoap.com/2010/11/07/mttr-mtbf-for-most-types-of-f/
20. “[...] listing human error as a root cause isn’t where you should end, it’s where you should start your investigation. Getting behind what led to a ‘human error’ is where the good stuff happens.” John Allspaw, former CTO @ Etsy https://www.kitchensoap.com/2011/04/07/resilience-engineering-part-i/
21. “All incidents can be worse.” Resilience Engineering: The What and How, John Allspaw, DevOpsDays DC 2019 John Allspaw, former CTO @ Etsy
22. 3. Истории от фронта
23. • Head of Infrastructure в Dext (преди известни като Receipt Bank) през последните 5 години • Програмист по душа, със силен интерес към инфраструктурата • Силен интерес към нещата “под капака” • Очарова се лесно от заплетени бъгове и инциденти Контекст: за мен
24. • Продуктова компания на около 10 години, ~500 човека • Няколко тясно-свързани услуги и сравнително хомогенна инфраструктура • The long game • Инженерен екип от около 120 човека, 13 човека инфраструктурен отдел • Remote working от самото начало Контекст: за Dext, част 1
25. Контекст: за Dext, част 2 • Основно уеб приложения: UI и API за мобилните, едно по-голямо user-facing • Предимно Ruby on Rails с PostgreSQL бекенд • Изцяло хостнати в AWS • Контейнери в self-managed Kubernetes • Self-managed ELK стек, Prometheus + Thanos, Grafana, Datadog • Tрафик ~15 mil reqs/day, 24/7 usage
26. ...от общо 223 инцидента (and counting), регистрирани от средата на 2015 г. досега. Пет примера
27. №1
28. След скорошна миграция от PostgreSQL 12 към 13, DBA екипа реагира на аларма, че една от логическите реплики е спряла да наваксва. №1 – репликацията се счупи!
29. №1 – репликацията се счупи! • Репликацията е спряла, поради грешка за unique index violation • Действително, има unique index грешка: основната база праща ред с имейл адрес, който вече съществува в таблицата • Оказва се, че на основната база са се появили дублирани стойности за някои полета. Изглежда като че не работят unique indexes!
30. №1 – какво се оказва? • С миграцията от PG 12 → 13, мигрирахме и от Ubuntu 16.04 към 20.04 • Процесът по миграция включва копиране на binary файловете на базата, вкл. индексите • С новата версия на Ubuntu идва и GNU libc 2.28 (Aug 2018), която носи “a major update of its Unicode locale data with new collation information.”
31. • “Колация” е колекция от правила, дефиниращи подредбата на текст (кой символ преди кой се води) • Тя определя как ще бъдат сортирани списък стрингове • Има много колации, от които можем да избираме • Колациите се променят с времето №1 – collation какво?
32. • Индексите в базите са на практика сортирани елементи и разчитат силно на колации • Ако промените колацията, променяте правилата на сортиране и… • Изведнъж някои елементи в индекса стават недостижими! №1 – колации и индекси в RDBMS
33. №1 – пример
34. • Изключително трудно да се оцени изцяло • Малко (за щастие) количество дублирани записи (адска мъка да се оправят, контакт с потребителите) • Неизвестно количество заявки, които не са връщали съществуващи резултати, защото не са намерили ключ в индекса №1 – ефекти от проблема
35. • Можело е да го избегнем, ако сме били пуснали index rebuild на новосъздадената PG 13 база, преди да я вкараме в употреба – имало го е в чеклиста, но сме си го спестили • Внимавайте с колациите :) №1 – изводи
36. №1 – ресурси • https://postgresql.verite.pro/blog/2018/08/27/glib c-upgrade.html • https://www.citusdata.com/blog/2020/12/12/dont-l et-collation-versions-corrupt-your-postgresql-ind exes/
37. №2
38. След една от първите ни миграции към Kubernetes на app, събиращ логове и статистики, забелязваме, че той започва да издиша, въпреки повечето ресурс. №2 – гърлото на бутилката
39. №2 – гърлото на бутилката • Преди е работело окей с 10-20 процеса, сега дори 80 не му стигат! • Започват да се затлачват други неща по тръбата – опашки, от които то трябва да консумира • Застрашава се видимостта ни към приложенията
40. №2 – фактите • Приложението е single-threaded и разчита на паралелизация с процеси • Нормалното време за обработка на заявки е стотни от секундата • През тази система обикновено текат 1000-2000 заявки в секунда
41. №2 – фактите • Не виждаме увеличение в броя requests към него • Гледайки average response time, не виждаме съществена промяна – приложението обработва заявки сравнително бързо и горе- долу за същото време, за което и преди
42. • Сещаме се да погледнем максималното време за изпълнение на заявките • Изскача нещо интересно – тук-таме има заявки, които отнемат 5 секунди • Малко са на фона на всички – няколко десетки заявки, на фона на хиляди, но! • При очакван throughput от 1-2к/секунда, да имаш няколко десетки запушени процеса е ☠ №2 – фактите
43. №2 – какво се оказва? • Точно 5 секунди е много съмнително • 5 секунди е default timeout на DNS клиентите • Kubernetes има нужда от специален DNS сървър за service discovery • Приложението ни прави по няколко DNS заявки на request • Особеност на DNS-а в Kubernetes умножава тези заявки x5
44. №2 – какво се оказва? => Претоварен DNS (CoreDNS) в Kubernetes.
45. №2 – изводи 1. Beware of averages! Предпочитайте персентили и хвърляйте око на максимумите. 2. Научете какво е percentile. Mean = 50th percentile, max = 100th percentile. Например, Response time 95th percentile = 1s значи, че 95% от всички requests са максимум 1s. 3. It’s always DNS¹! 4. ¹Or BGP
46. №3
47. Забелязваме, че за последния месец, цената за трафик, която плащаме на AWS, е скочила с близо 30% – с почти $3000/месец! А нямаме такъв растеж на заявките. №3 – $3000/месец повече в AWS сметката
48. • Имаме система за background jobs (Sidekiq), работеща с Redis • Донадградили (побългарили) сме си я • Събираме статистика за състоянието ѝ от Redis на всеки 10 секунди • Не сме догледали и взимаме всички payloads на всички enqueued jobs • Имаме едни опашки с хиляди jobs, някои от които са мегабайти №3 – какво се оказа?
49. => Огромен трафик между Redis сървъра и приложението ни, който е превъртял електромера. №3 – какво се оказа?
50. 1. Безос летя в космоса заради такива като нас 2. Public cloud сметката става много трудна за контрол от едно ниво на сложност нататък 3. Парите за трафик са най-трудното нещо за разпарчатосване и разгадаване 4. Measure & observe: ако можете да си пуснете някакъв вид автоматизиран anomaly detection => 🥇 №3 – изводи
51. №4
52. №4 – автоматичен failover код Звъни аларма, основното ни приложение е долу. Почти всички потребители виждат грозни HTTP 502/504 грешки. Инцидентът продължава 12 минути.
53. 1. Деплойваме по няколко пъти на ден, рутинно 2. Деплоят е blue-green – вдига второ копие на приложението, чака то да стане готово, превключва трафика към него и чак накрая спира старото копие 3. Написали сме failover код, който да върне трафика към оригиналното копие, ако с новото нещо не е наред №4 – автоматичен failover код
54. 1. Върви деплой. Вдигнали сме новото копие. То е готово. Пуснали сме трафик към него и чакаме да видим, че е потекъл. 2. На 1 от 19-те машини проверката за потекъл трафик не минава. Всички останали 18 са наред и вече спират старото копие. 3. На проблемната машина тръгва rescue код, който връща трафика глобално към старото копие. Което вече има само 1 сървър... №4 – какво се оказа?
55. => Сами се прецакваме с калпав failover код. №4 – какво се оказа?
56. 1. Error handling-ът е трудно начинание 2. Know your tools! Няколко пропуска в разбирането ни за Ansible (който изпълнява деплоите към онзи момент) са допринесли за пропуските ни в логиката. №4 – изводи
57. №5
58. №5 – email-in down for 11 hours Рано сутрин от съпорта ни съобщават за множество сигнали от клиенти, че не обработваме документите, които ни изпращат по имейл.
59. №5 – email-in down for 11 hours 1. Клиентите могат да изпращат документи на специален имейл адрес 2. Ние ги обработваме с верига от background jobs (Sidekiq) 3. Част от jobs във веригата са “unique” (с наша, побългарена имплементация) – ако вече има нареден job, не се нарежда втори
60. №5 – какво се оказа? 1. “Uniqueness” кодът ни е неатомарен и сме ударили рядък случай, в който сме създали unique token за job, но не сме наредили самия job 2. Това води до stuck-ване на целия email-in processing pipeline 3. Имаме аларма за това! 4. Но тя била mute-ната преди 1 година и забравена...
61. • 15 минути триаж и премахване на “запушването” и • 8 часа борба с последствията от огромния беклог... №5 – ефект
62. 1. Писане на атомарен код е сложно 2. Винаги mute-вайте за ограничено време 3. Know your tools! Клиентската библиотека за Redis в Ruby прави 1 silent retry на всички операции и чупи гаранциите за атомарност на някои команди №5 – изводи
63. 4. Още (random) изводи и съвети
64. Съвети (предимно web-app specific) 1. Разучете добре всяко звено на request пътя 2. Събирайте логове от всяко от тях 3. (Cloud) LB logs = много ценни! AWS LBs са били безупречно стабилни до момента и логовете им – особено полезни 4. Опознайте добре мониторинг инструментите си; свикнете с “нормалното” 5. Дефинирайте поне бизнес аларми
65. 1. Из документацията на New Relic: “the default number of traces at the trace origin is 10 traces per minute” 2. Обърнете внимание на sampling profiling – много observability инструменти са sampling profilers (какъвто е “distributed tracing” продукта на New Relic) Съвети, част 2
66. APM е добре, но пробвали ли сте ASH (active session history)?
68. Благодаря! mitio me@ddimiitrov.name @mitio ddimitrov.name