Пераклад артыкула падрыхтаваны спецыяльна для студэнтаў курса , Які стартуе ўжо сёння!
Вы калі-небудзь выпускалі новы сэрвіс у прадакшн? Ці можа займаліся суправаджэннем такіх сэрвісаў? Калі так, то чым вы кіраваліся? Што для прадакшэна добра, а што дрэнна? Як вы навучаеце новых удзельнікаў каманды рэлізам або суправаджэнні існуючых сэрвісаў.
Большасць кампаній у частцы практык прамысловай эксплуатацыі ў выніку прыходзяць да падыходаў "Дзікага Захаду". Кожная каманда з дапамогай спроб і памылак самастойна вызначаецца з інструментамі і лепшымі практыкамі. Але гэта часта ўплывае не толькі на поспех праектаў, але і на інжынераў.
Метад спроб і памылак стварае асяроддзе, у якім распаўсюджаны пошук вінаватых і перакладанне адказнасці. Пры такіх паводзінах становіцца ўсё цяжэй вучыцца на памылках і не паўтараць іх ізноў.
Паспяховыя арганізацыі:
- ўсведамляюць неабходнасць гайдлайнаў для прадакшэна,
- вывучаюць лепшыя практыкі,
- пачынаюць абмеркаванне пытанняў гатоўнасці да прадакшэну пры распрацоўцы новых сістэм або кампанентаў,
- забяспечваюць выкананне правіл падрыхтоўкі да прадакшэну.
Падрыхтоўка да прадакшэну ўключае працэс "рэўю". Рэўю можа быць у выглядзе чэкліста або набору пытанняў. Рэўю можна рабіць уручную, аўтаматычна ці абодвума спосабамі. Замест статычных спісаў патрабаванняў можна зрабіць шаблоны чэклістаў, якія адаптаваць пад канкрэтныя патрэбы. Такім чынам, інжынерам можна даць спосаб успадкаваць веды і дастатковую гнуткасць, калі гэта патрабуецца.
Калі правяраць сэрвіс на гатоўнасць да прадакшэну?
Праверку гатоўнасці для прадакшэна карысна праводзіць не толькі непасрэдна перад рэлізам, але і пры перадачы іншай камандзе эксплуатацыі або новаму супрацоўніку.
Рабіце праверку, калі:
- Выпускаеце новы сэрвіс у прадакшн.
- Перадаеце эксплуатацыю прадакшн-сэрвісу іншай камандзе, такі як SRE.
- Перадаеце эксплуатацыю прадакшн-сэрвісу новым супрацоўнікам.
- Арганізуеце тэхпадтрымку.
Чэкліст праверкі гатоўнасці да прадакшэну
Некаторы час таму, у якасці прыкладу, я чэкліст праверкі гатоўнасці да прадакшэну. Нягледзячы на тое, што гэты спіс з'явіўся пры працы з кліентамі Google Cloud, ён будзе карысны і прымяняецца за межамі Google Cloud.
Праектаванне і распрацоўка
- Распрацуйце які прайграваецца працэс зборкі, не патрабавальны доступу да вонкавых сэрвісаў і не які залежыць ад збою вонкавых сістэм.
- У перыяд праектавання і распрацоўкі вызначыце і ўсталюеце SLO для вашых сэрвісаў.
- Дакументуйце чаканні па даступнасці знешніх сэрвісаў, ад якіх вы залежыце.
- Пазбягайце адзінай кропкі адмовы, прыбраўшы залежнасці ад аднаго глабальнага рэсурсу. Рэпліцыруйце рэсурс або выкарыстоўвайце рэзервовы варыянт, калі рэсурс недаступны (напрыклад, жорстка закадаванае значэнне).
Упраўленне канфігурацыяй
- Статычную, невялікую і не сакрэтную канфігурацыю можна перадаваць праз параметры каманднага радка. Для ўсяго астатняга выкарыстоўвайце сэрвісы захоўвання канфігурацыі.
- Дынамічная канфігурацыя павінна мець рэзервовыя настройкі ў выпадку недаступнасці сэрвісу канфігурацыі.
- Канфігурацыя асяроддзя распрацоўкі не павінна быць злучана з канфігурацыяй прадакшэна. Інакш гэта можа прывесці да доступу з асяроддзя распрацоўкі да прадакшн-сэрвісаў, што можа выклікаць праблемы канфідэнцыйнасці і уцечкай дадзеных.
- Дакументуйце тое, што можа быць наладжана дынамічна, і апішыце рэзервовыя паводзіны, калі сістэма дастаўкі канфігурацыі будзе недаступная.
Упраўленне рэлізамі
- Падрабязна дакументуйце працэс рэлізу. Апішыце як рэлізы ўплываюць на SLO (напрыклад, часавае павелічэнне затрымак з-за промахаў кэша).
- Дакументуйце канарэечныя рэлізы.
- Распрацуйце план аналізу канарэечных рэлізаў і, пры магчымасці, механізмы аўтаматычнага адкату.
- Пераканайцеся, што адкаты могуць выкарыстоўваць тыя ж працэсы, што і разгортванне.
Прыдатнасць да маніторынгу (Observability)
- Пераканайцеся, што збіраецца набор метрык, неабходных для SLO.
- Упэўніцеся, што можна адрозніць паміж сабой кліенцкія і серверныя дадзеныя. Гэта важна для пошуку прычын няспраўнасцяў.
- Наладзьце абвесткі, каб паменшыць працавыдаткі. Напрыклад, выдаліце абвесткі, выкліканыя руціннымі аперацыямі.
- Калі вы выкарыстоўваеце Stackdriver, то ўключыце метрыкі платформы GCP у свае дашборды. Наладзьце абвесткі для GCP-залежнасцяў.
- Заўсёды распаўсюджвайце ўваходную трасіроўку. Нават калі вы не ўдзельнічаеце ў трасіроўцы, гэта дазволіць сэрвісам ніжэйшага ўзроўню адладжваць праблемы ў прадакшэне.
Абарона і бяспека
- Пераканайцеся, што ўсе знешнія падключэння зашыфраваны.
- Пераканайцеся, што вашыя прадакшн-праекты маюць правільную настройку IAM.
- Выкарыстоўвайце сеткі для ізаляцыі груп асобнікаў віртуальных машын.
- Выкарыстоўвайце VPN для бяспечнага падлучэння да выдаленых сетак.
- Дакументуйце і маніторыце доступ карыстальнікаў да дадзеных. Упэўніцеся, што ўвесь доступ карыстальнікаў да дадзеных правяраецца і лагіруецца.
- Упэўніцеся, што канчатковыя кропкі для адладкі абмежаваныя ACL.
- Санітуйце карыстацкі ўвод. Наладзьце абмежаванні памеру карыснай нагрузкі для карыстацкага ўводу.
- Пераканайцеся, што ваш сэрвіс можа выбарча блакаваць уваходны трафік для асобных карыстальнікаў. Гэта дазволіць блакаваць парушэнні, не ўплываючы на іншых карыстальнікаў.
- Пазбягайце вонкавых канчатковых кропак, якія ініцыююць вялікую колькасць унутраных аперацый.
Планаванне магутнасцей
- Дакументуйце, як маштабуецца ваш сэрвіс. Напрыклад: колькасць карыстальнікаў, памер уваходнай карыснай нагрузкі, колькасць уваходных паведамленняў.
- Дакументуйце патрабаванні да рэсурсаў для вашага сэрвісу. Напрыклад: колькасць выдзеленых асобнікаў віртуальных машын, колькасць асобнікаў Spanner, спецыялізаванае абсталяванне, такое як GPU ці TPU.
- Дакументуйце абмежаванні рэсурсаў: тып рэсурсу, рэгіён і т. д.
- Дакументуйце абмежаванні квот для стварэння новых рэсурсаў. Напрыклад, абмежаванне колькасці запытаў GCE API, калі вы карыстаецеся API для стварэння новых інстансаў.
- Разгледзьце магчымасць правядзення нагрузачных тэстаў для аналізу зніжэння прадукцыйнасці.
Вось і ўсё. Да сустрэчы на занятках!
Крыніца: habr.com