Адказвайце за сэрвіс пасля разгортвання
ЗавершанаВызначайце карысныя сігналы сэрвісу, рашэнні пры інцыдэнтах, аднаўленне і суправаджэнне. Захоўвайце эксплуатацыйную адказнасць бачнай пасля завяршэння генерацыі кода.
Выдавец TaigaЯк мы пішам
Праверце сваё разуменнеПраверка даступнасці вяртае HTTP 200, але экспарты не змяшчаюць запісаў праз зламаную аўтарызацыю. Што гэта паказвае?Выканайце практыкаванне
Чаму вы навучыцеся
- Вызначаць сігнал сэрвісу з пункту гледжання карыстальніка.
- Аддзяляць каардынацыю інцыдэнту ад тэхнічнага даследавання.
- Планаваць суправаджэнне і аднаўленне як пастаянныя абавязкі.
Вызначце сэрвіс, ад якога залежаць карыстальнікі
Разгортванне робіць праграму даступнай. Эксплуатацыя захоўвае яе карыснай пры зменах карыстальнікаў, залежнасцей, трафіку і патрабаванняў. Генератар кода не прыбірае гэтай пастаяннай працы.
Для выдуманага экспарту даных кліентаў карыстальнікам патрэбна больш, чым даступная старонка. Ім патрэбныя дазволеныя запісы ў неабходным фармаце за прымальны час. Ім таксама трэба, каб сэрвіс прадухіляў доступ да даных іншай арганізацыі.
Назавіце адказнага да выпуску. Запішыце, хто рэагуе па-за звычайным працоўным часам, калі гэта частка абавязацельстваў сэрвісу. Пастаўшчык можа выконваць частку працы, але арганізацыі ўсё роўна патрэбны выразны парадак рашэнняў і камунікацыі.
Выбірайце сігналы, якія падтрымліваюць дзеянні
Паказчык узроўню сэрвісу, або SLI, вымярае вызначаную ўласцівасць паводзін сэрвісу. Мэта ўзроўню сэрвісу, або SLO, задае мэту для гэтага паказчыка на ўказаны перыяд. Выбірайце мэту з патрэб карыстальнікаў і эксплуатацыйных магчымасцей.
Рэкамендацыі Google SRE тлумачаць гэты падыход і выкарыстанне бюджэту памылак для рашэнняў аб надзейнасці. Не капіруйце мэту іншага сэрвісу без праверкі яе сэнсу. Рэкамендацыі па SLO, прыклад палітыкі бюджэту памылак.
Для экспарту вызначце, што лічыцца паспяховым запытам, які падлягае апрацоўцы. Аддзяляйце чаканыя адмовы ад збояў сістэмы. Дакументуйце выключэнні, каб метрыка не магла палепшыцца толькі праз хаванне складаных запытаў.
| Сігнал | Што дапамагае выявіць | Істотнае абмежаванне |
|---|---|---|
| Публічная праверка даступнасці | Немагчыма звярнуцца да сэрвісу | Не правярае працэс карыстальніка, які ўвайшоў у сістэму |
| Завяршэнне экспарту і затрымка | Дапушчальныя запыты не выконваюцца або займаюць занадта шмат часу | Патрабуе дакладнага азначэння поспеху |
| Праверкі адмовы ў аўтарызацыі | Крытычная мяжа перастае працаваць | Ахоплівае пратэставаныя ўмовы |
| Сігналы рэсурсаў і залежнасцей | Верагодную ўнутраную прычыну | Самі па сабе не апісваюць уплыву на карыстальніка |
Не запісвайце поўныя экспарты ў журналы дзеля лепшай бачнасці. Збірайце мінімальную інфармацыю, патрэбную для дыягностыкі праблемы, і абараняйце доступ да яе.
Падрыхтуйце рэагаванне на інцыдэнт
Вырашыце, хто каардынуе, хто даследуе і хто паведамляе. У невялікай камандзе гэтыя ролі можна сумяшчаць, але абавязкі павінны заставацца выразнымі. Захоўвайце запіс назіранняў і дзеянняў.
Рэкамендацыі Google па рэагаванні на інцыдэнты падкрэсліваюць каардынацыю і камунікацыю разам з тэхнічным змякчэннем наступстваў. Тэхнічна правільнае выпраўленне ўсё роўна можа пакінуць карыстальнікаў без інфармацыі або некалькіх удзельнікаў з супярэчлівымі зменамі. Рэагаванне на інцыдэнты.
Агент можа абагульняць журналы або параўноўваць гіпотэзы ва ўхваленых межах даных. Ён не павінен атрымліваць неабмежаваных паўнамоцтваў у production праз тэрміновасць інцыдэнту. Выкарыстоўвайце вызначаны шлях эскалацыі для выключнага доступу.
Практыкуйце аднаўленне і фінансуйце суправаджэнне
Тэстуйце працэдуру аднаўлення з рэпрэзентатыўнымі выдуманымі данымі. Вызначце, чаго адкат кода не можа адмяніць, уключаючы выдаленыя запісы або ўжо адпраўленыя паведамленні. Запісвайце час і інфармацыю, патрэбныя для аднаўлення сэрвісу.
Прызначце пастаянную працу: абнаўленне залежнасцей, перагляд доступу, падаўжэнне сертыфікатаў, дзе гэта дарэчы, змены магутнасці і выпраўленне дакументацыі. Сэрвіс без рэсурсаў суправаджэння назапашвае абавязацельствы пасля вычарпання бюджэту запуску.
Пасля інцыдэнту выбірайце паляпшэнні, якія вырашаюць назіраныя прычыны. Звязвайце іх з рэалізацыяй і праверкай. Гэта замыкае жыццёвы цыкл: эксплуатацыйныя доказы змяняюць тое, што каманда вызначае і стварае далей.
Выканайце практыкаванне
Напішыце аднастаронкавую эксплуатацыйную нататку для выдуманага экспарту даных кліентаў. Уключыце адзін сігнал з боку карыстальніка, яго мэтавае значэнне, атрымальніка апавяшчэння, бяспечнае першае дзеянне, мяжу аднаўлення і адказнага за суправаджэнне. Укажыце, чаго маніторынг не можа выявіць.
Спампаваць працоўны ліст (Markdown)Зняцце гэтай пазнакі выдаляе ўвесь прагрэс, захаваны ў гэтым браўзеры.
Прагрэс застаецца ў гэтым браўзеры. Без уліковага запісу і адсочвання.
Крыніцы і дадатковыя матэрыялы
- Google SRE: Implementing SLOs ↗
- Google SRE: Incident Response ↗
- Google SRE: Example Error Budget Policy ↗