Наша каманда кахае эксперыменты. Кожны Слёрм - гэта не статычнае паўтарэнне папярэдніх, а асэнсаванне вопыту і пераход ад добрага да лепшага. Але са мы вырашылі прымяніць абсалютна новы фармат – даць удзельнікам умовы, максімальна набліжаныя да «баявых».
Калі коратка абмаляваць, чым мы займаліся на інтэнсіўе: «Будуем, ламаем, чынім,
вывучаем». SRE мала чаго варта ў голай тэорыі - толькі практыка, рэальныя рашэнні, рэальныя праблемы.
Удзельнікі былі падзелены на каманды, каб бадзёры спаборніцкі дух не даў нікому заснуць або запусціць "Angry Birds" на iPhone па прыкладзе Дзмітрыя Анатольевіча.
Праблемы, глюкі, багі і задачы забяспечвалі ўдзельнікам чатыры ментары. Іван Круглоў, Principal Developer у Booking.com (Нідэрланды). Бэн Тайлер, Principal Developer у Booking.com (ЗША). Эдуард Мядзведзеў, CTO у Tungsten Labs (Германія). Яўген Варава, распрацоўшчык шырокага профілю ў Google (Сан-Францыска).
Ды яшчэ і ўдзельнікі падзелены на каманды - і спаборнічаюць адзін з адным. Цікава?
Іван, Бэн, Эдуард і Яўген з добрым ленінскім прыжмурваннем глядзяць на бедных удзельнікаў Слёрм SRE перад пачаткам спаборніцтва.
Такім чынам задача:
Мы наш, мы новы свет пабудуем...
Ёсць сайт-агрэгатар білетаў у кіно. Інцыдэнты прыдумляюць ментары ў загадзя прапрацаваным сцэнары (хоць ніхто не выключае асабліва вытанчаную і падступную імправізацыю), працаздольнасць сайта апісваецца рознымі метрыкамі. Праблемы могуць быць самымі рознымі: білеты тэатра «Мулен Руж» не падгружаюцца ў базу; постэры фільмаў і спектакляў падгружаюцца ў базу больш, чым за 10 секунд; апісанне асобнага фільма падвісае; 0,1% заказаў трапляюць ужо на зарэзерваваныя месцы; перыядычна на салодкае адвальваецца на хвіліну-дзве сістэма апрацоўкі плацяжоў. І шматлікае-многае-многае непрыемнае, што можа зваліцца на ўдзельніка Слёрма SRE на яго рэальнай працы.
Мы гатовы справіцца з усім… і з усімі.
Наш шматпакутны сайт складаецца з некалькіх мікрасэрвісаў. Яго задача - агрэгацыя дадзеных аб сеансах, коштах і вольных месцах з усіх кінатэатраў, ён паказвае анонсы фільмаў, дае абраць кінатэатр, сеанс, зала і месца, забраніраваць і аплаціць квіткі. Увогуле ўсё, пра што глядач можа толькі марыць. Толькі вось карыстач нават не падазрае, якая тытанічная дужанне за стабільнасць і даступнасць сайта ідзе ўсярэдзіне.
Для сайта на інтэнсіўе мы сфарміравалі паказчыкі SLO, SLI, SLA, распрацавалі архітэктуру і інфраструктуру, задэплоілі сайт, настроілі маніторынг і алертынг. І панеслася.
SLO, SLI, SLA
SLI - індыкатары ўзроўню абслугоўвання. SLO - мэты ўзроўню абслугоўвання. SLA – пагадненні аб узроўні абслугоўвання.
SLA — тэрмін метадалогіі ITIL, які абазначае фармальны дагавор паміж заказчыкам паслугі і яе пастаўшчыком, які змяшчае апісанне паслугі, правы і абавязкі бакоў і, самае галоўнае, узгоднены ўзровень якасці прадастаўлення гэтай паслугі.
SLO - гэта мэта ўзроўню абслугоўвання: мэтавае значэнне або дыяпазон значэнняў для ўзроўню абслугоўвання, які вымяраецца SLI. Нармальным значэннем для SLO з'яўляецца "SLI ≤ мэтавага значэння" або "ніжняя мяжа ≤ SLI ≤ верхняя мяжа".
SLI з'яўляецца індыкатарам узроўня абслугоўвання - старанна вызначанай колькаснай мерай аднаго з аспектаў які прадстаўляецца ўзроўня абслугоўвання. Для большасці сэрвісаў у якасці ключавога SLI лічаць затрымку запыту - колькі часу патрабуецца для вяртання адказу на запыт. Іншыя распаўсюджаныя SLI уключаюць частату памылак, часта выяўляецца як дзель усіх атрыманых запытаў, і прапускную здольнасць сістэмы, звычайна вымяраную ў запытах у секунду.
Перш за ўсё мы зламаем самалёты, ну а дзяўчын, а дзяўчын потым…
Унутраныя і знешнія фактары з першых жа хвілін пачалі "псаваць" SLO. Звалілася на галаву адмінам усё - і памылкі распрацоўшчыкаў, і адмовы інфраструктуры, і наплыў наведвальнікаў, і DDoS-напады. Усё тое, што пагаршае SLO.
«- Дарагія ўдзельнікі, спяшаюся вас парадаваць, перш за ўсё ў вас падае ... усё!»
Па ходзе справы спікеры разбіралі ўстойлівасць, error budget, практыку тэставання, кіраванне перапыненнямі і аперацыйнай нагрузкай.
Не качагары мы, не цесляры…
Тут удзельнікі пачалі правіць - галоўнае зразумець, за што хапацца першым.
«- Божа, я ніколі не бачыў, каб гэта ламалася так, у такім выглядзе і ў такой позе!»
Такім чынам, здарылася аварыя. Сэрвіс апрацоўкі плацяжоў лёг. Як дзейнічаць, каб аднавіць працаздольнасць у мінімальныя тэрміны?
Эксперты ласкава пазіраючы на ўдзельнікаў рыхтуюць чарговую каверзу.
Кожная каманда арганізуе працу групы па ліквідацыі аварыі - падключае калегаў, апавяшчае інтарэсантаў (stakeholders). Заадно выстройваюцца прыярытэты. Так удзельнікі трэніраваліся працаваць пад ціскам ва ўмовах абмежаванага часу.
«- Гэта што за жах вылез?!»
Выдыхнулі… і скончылі практыкаванне
Разам са спікерамі пасля кожнай вырашанай праблемы і часова стабілізаванага сайта каманды вывучала інцыдэнты з кропкі зрок SRE. Дэталёва аналізавалі праблемы - прычыны ўзнікнення, ход ліквідацыі. Пасля гэтага як камандна, так і калектыўна прымалі рашэнне па іх далейшаму прадухіленню: як палепшыць маніторынг, як правільна змяніць архітэктуру, як адкарэктаваць падыход да распрацоўкі і эксплуатацыі, як выправіць рэгламенты. Спікеры прадэманстравалі практыку правядзення post-mortem.
«- Хто яшчэ хоча пакут! - Я!»
На электронным табло строга і дакладна фіксаваліся поспехі каманд.
За першыя месцы - прэмія ад стэйкхолдэраў.
Крыніца: habr.com