Задавайце бяспечныя межы самааднаўлення
ЗавершанаАўтаматызуйце вядомыя дзеянні аднаўлення з выразнымі паўнамоцтвамі, праверкай і ўмовамі спынення. Аддзяляйце аднаўленне падчас працы ад змянення праграмы.
Выдавец TaigaЯк мы пішам
Праверце сваё разуменнеКантролер двойчы перазапусціў працэс-апрацоўшчык. Чарга працягвае расці, а база даных недаступная. Што павінна зрабіць палітыка?Выканайце практыкаванне
Чаму вы навучыцеся
- Адрозніваць самааднаўленне ад сталага выпраўлення праграмы.
- Вызначаць абмежаваную палітыку аднаўлення і незалежныя праверкі поспеху.
- Распазнаваць, калі аўтаматызацыя павінна спыніцца і перадаць пытанне адказнаму.
Аднаўляйце вядомы стан
Самааднаўленне аўтаматычна выяўляе вызначаны збой і спрабуе выканаць дазволенае дзеянне аднаўлення. Прыклады — перазапуск працэсу, які спыніўся, або замена няспраўнага асобніка. Дзеянне павінна адпавядаць збою і мадэлі стану сэрвісу.
Kubernetes можа замяняць няспраўныя асобнікі рабочай нагрузкі і прыводзіць стан у адпаведнасць з зададзеным. Гэта не выпраўляе памылковую логіку праграмы або кожны збой сховішча. Аднаўленне інфраструктуры і правільнасць праграмы патрабуюць розных праверак. Самааднаўленне Kubernetes.
Вызначце мэту перад механізмам. Аднавіць экспарт азначае, што дапушчальная праца правільна завяршаецца. Працуючы кантэйнер — толькі адна перадумова.
Аддзяляйце тры віды змен
| Змена | Прыклад | Неабходнае рашэнне |
|---|---|---|
| Аднаўленне падчас працы | Замяніць адзін няспраўны працэс-апрацоўшчык без стану | Загадзя ўхваленая палітыка аднаўлення можа гэта дазволіць |
| Выпраўленне праграмы | Выправіць уцечку памяці, якая спыняе працэс-апрацоўшчык | Праверка кода, тэсты, меры кантролю выпуску і праверка ў production |
| Змена палітыкі | Павялічыць дазволеную частату перазапуску або абсяг доступу | Яўнае ўхваленне адказнага за палітыку |
Агент можа прапанаваць выпраўленне пасля аднаўлення. Гэтая прапанова — новая змена праграмы. Яна не павінна атрымліваць неабмежаваныя паўнамоцтвы ад кантролера аднаўлення.
Кантролер таксама не павінен рэдагаваць уласныя крытэрыі поспеху, калі праверка не праходзіць. Інакш сістэма можа паведамляць пра паляпшэнне, не паляпшаючы сэрвіс.
Напішыце палітыку аднаўлення перад яе ўключэннем
Наступная палітыка выдуманая. Яе лічбы ілюструюць праектныя выбары; гэта не рэкамендаваныя стандартныя значэнні.
| Поле палітыкі | Выдуманае правіла працэсу-апрацоўшчыка экспарту |
|---|---|
| Умова запуску | Сігнал прысутнасці апрацоўшчыка адсутнічае 90 секунд, а ў чарзе ёсць праца |
| Перадумовы | Іншы апрацоўшчык працаздольны; праверкі залежнасцей паспяхова завяршаюцца; няма падазрэння на несанкцыянаванае пранікненне або збой цэласнасці |
| Дазволенае дзеянне | Замяніць адзін апрацоўшчык з выкарыстаннем бягучага ўхваленага артэфакта |
| Абарона стану | Задачы выкарыстоўваюць сховішча з устойлівым захаваннем даных і правераны ключ ідэмпатэнтнасці |
| Ліміт | Не больш за дзве замены за 15 хвілін; ніколі больш за адну адначасова |
| Паўза | Пачакаць пяць хвілін пасля замены перад наступнай спробай |
| Поспех | Сінтэтычная задача правільна завяршаецца, а закранутая чарга пачынае скарачацца |
| Спыненне і эскалацыя | Любая перадумова не выканана, ліміт дасягнуты або поспех немагчыма праверыць |
Выкарыстоўвайце ідэнтычнасць з найменшымі прывілеямі. Запісвайце версію палітыкі, доказы ўмовы запуску, дзеянне, рэсурс і вынік. Забяспечце незалежны спосаб адключыць кантролер. Вызначце чалавека, які атрымлівае эскалацыю.
Тэстуйце збоі разам з паспяховым аднаўленнем
Паўторная спроба можа паўтарыць пабочны эфект. Працэс-апрацоўшчык можа захаваць файл і спыніцца перад пацвярджэннем задачы. Праверце ідэмпатэнтнасць перад дазволам паўторнага выканання. Глядзіце прыклад збою cloud native.
Паўторныя спробы таксама могуць узмацніць перагрузку залежнасці. Выкарыстоўвайце абмежаваныя спробы, тайм-аўты і адпаведнае павелічэнне затрымкі. Пазбягайце сінхронных паўторных спроб ва ўсіх асобніках. AWS тлумачыць, чаму backoff і jitter дапамагаюць паменшыць такое ўзмацненне. Рэкамендацыі па паўторных спробах.
Праверце выдуманую палітыку на трох выпадках. Адзін спынены апрацоўшчык павінен аднавіцца. Недаступнасць базы даных павінна перашкодзіць паўторнай замене. Нявызначаны збой цэласнасці павінен спыніць аўтаматызацыю і запытаць рашэнне аб рэагаванні.
Таксама правярайце адсутнасць тэлеметрыі. Адсутны сігнал прысутнасці можа азначаць збой апрацоўшчыка або шляху збору. Кантролеру патрэбныя дастатковыя доказы для свайго дзеяння, а не ўпэўненасць у тлумачэнні AI.
Вымярайце, ці дапамагае палітыка
Запісвайце правераныя аднаўленні, няўдалыя спробы, эскалацыі, паўторную працу і час уплыву на карыстальнікаў. Параўноўвайце іх з папярэднім метадам эксплуатацыі ў падобных умовах.
Захоўвайце асноўны дэфект як інжынерную задачу. Паўторны перазапуск працэсу з уцечкай памяці можа паменшыць непасрэдны ўплыў, пакуль уцечка працягваецца. Працягвайце з урокам пра самаўдасканаленне, каб звязаць назіранне са сталым выпраўленнем.
Выканайце практыкаванне
Спраектуйце палітыку аднаўлення для выдуманага працэсу-апрацоўшчыка экспарту з гэтага ўрока. Укажыце ўмову запуску, выключэнні, дазволенае дзеянне, ліміт паўторных спроб, паўзу, праверку поспеху і адказнага за эскалацыю. Праверце яе пры недаступнасці базы даных і невядомым збоі цэласнасці даных.
Спампаваць працоўны ліст (Markdown)Зняцце гэтай пазнакі выдаляе ўвесь прагрэс, захаваны ў гэтым браўзеры.
Прагрэс застаецца ў гэтым браўзеры. Без уліковага запісу і адсочвання.
Крыніцы і дадатковыя матэрыялы
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗