Инженеринг за надеждност на сайта - курс 65 000 rub. от Slurm, обучение, Дата 1 януари 2024 г.

instagram viewer

ДЕН 1: Начална сесия на AMA

Ще обсъдим целите и задачите на курса, а също така ще ви кажем какво е SRE и ще го разделим на екипи.

Откриване на 2 теоретични теми:

Тема 1: Мониторинг

• Защо е необходим мониторинг?
• Процентили
• Предупреждаване
• Наблюдаемост

Тема 2: Теория на SRE

• SLO, SLI, SLA
• Издръжливост
• Бюджет за грешка

ДЕН 2: анализ на практики и казуси

практика: Изработка на основно табло и настройка на необходимите сигнали

практика: Добавяне на SLO/SLI + сигнали към таблото за управление

практика: Първо зареждане на системата

Решение на случай 1: зависимост надолу по веригата.

В една голяма система има много взаимозависими услуги и те не винаги работят еднакво добре. Особено неприятно е, когато услугата ти е изрядна, но съседната, от която зависиш, периодично пада.

Образователният проект ще попадне точно в тези условия, а вие ще гарантирате, че той все още произвежда качество на възможно най-високо ниво.

ДЕН 3: AMA сесия, отговори на въпроси

Отваря се достъп до 2-ри теоретичен модул:

Решаване на проблеми с околната среда и архитектурата

Вторият модул е ​​изграден около решаването на два случая: зависимост нагоре по веригата и архитектурни проблеми. Лекторите ще говорят за управление на инциденти, правила за пожарната и работа с аутопсии и ще предоставят шаблони, които можете да използвате във вашия екип.

Тема 3: Управление на инциденти

• Инженеринг на устойчивостта
• Как се формира пожарната
• Колко ефективен е вашият екип при инцидента?
• 7 правила за лидер на инциденти
• 5 правила за пожарникар
• HiPPO - мнение на най-добре платения човек. Лидер комуникации

TТема 4: Инструменти Varrum и управление на предупреждения.

Най-добри практики на други компании в организирането на управление на инциденти.

ДЕН 4: анализ на практики и казуси

Решение на случай 2: зависимост нагоре по веригата.

Едно е, когато зависиш от услуга с ниско SLO. Друг е въпросът, когато услугата ви е еднаква за други части на системата. Това се случва, ако критериите за оценка не са последователни: например отговаряте на заявка в рамките на секунда и я считате за успешна, но зависимата услуга чака само 500 московско време и напуска с грешка.

В случая ще обсъдим важността на хармонизирането на показателите и ще се научим да гледаме на качеството през очите на клиента.

Решение на случай 3: проблеми с базата данни.

Базата данни също може да бъде източник на проблеми. Например, ако не наблюдавате релето за репликация, репликата ще остарее и приложението ще върне стари данни. Освен това отстраняването на грешки в такива случаи е особено трудно: сега данните са непоследователни, но след няколко секунди вече не са последователни и не е ясно каква е причината за проблема.

Чрез случая ще почувствате цялата болка от отстраняването на грешки и ще научите как да предотвратите подобни проблеми.

практика: Пишем постмортем по предишния случай и го обсъждаме с лекторите.

ДЕН 5: AMA сесия, отговори на въпроси

AMA сесия и отговори на въпроси по предишни теми.

Отваря се достъп до 3-ти теоретичен модул:

Защита на трафика и освобождаване на канарчета

В третия модул ще анализираме казус, посветен на проблем с околната среда (ще има подробен анализ на Health Проверка), а също така ще анализираме стъпка по стъпка как да внедрим SRE в компании и ще научим опита на компаниите, в които работят лекторите интензивен

Тема 5: Проверка на здравето

• Проверка на здравето в Kubernetes
• Службата ни още ли е жива?
• Exec сонди
• InitialDelaySeconds
• Вторичен здравен порт
• Sidecar Health Server
• Сонда без глава
• Хардуерна сонда

Тема 6: Методи за внедряване

Тема 7: Включване в проекта SRE

Големите компании често формират отделен SRE екип, който поема услугите на други отдели за поддръжка. Но не всяка услуга е готова да бъде приета за поддръжка. Ще ви кажем на какви изисквания трябва да отговаря. Лекторите също ще споделят своя опит, как са внедрили SRE и какви грешки са направили.

ДЕН 6: анализ на практики и казуси

Решение на случай 4: има проблем с околната среда, невъзможно е да се купят билети.

Задачата на Healthcheck е да открие повредена услуга и да блокира трафика към нея. И ако смятате, че за това е достатъчно да направите заявка до услугата с root и да получите отговор, тогава вие грешите: дори ако услугата отговори, това не гарантира нейната работа - могат да възникнат проблеми в заобикалящата среда.

Чрез този случай ще научите как да конфигурирате правилния Healthcheck и да не позволявате на трафика да отива там, където не може да бъде обработен.

Обобщаване