Вебинардың дыбысы нашар, сондықтан біз оны транскрипцияладық.
Менің атым Медведев Эдуард. Бүгін мен SRE дегеніміз не, SRE қалай пайда болды, SRE инженерлерінің жұмыс критерийлері қандай, сенімділік критерийлері туралы, аздап оның мониторингі туралы сөйлесемін. Біз шыңдарға шығамыз, өйткені сіз бір сағатта көп нәрсені айта алмайсыз, бірақ мен қосымша шолу үшін материалдарды беремін, және біз бәріміз сізді күтеміз . қаңтардың аяғында Мәскеуде.
Алдымен, SRE дегеніміз не - сайт сенімділігі инженериясы туралы сөйлесейік. Ал ол жеке ұстаным, жеке бағыт ретінде қалай пайда болды. Мұның бәрі дәстүрлі даму шеңберлерінде Dev және Ops екі мүлдем басқа команда, әдетте екі мүлдем басқа мақсаттары бар екендігімен басталды. Әзірлеу тобының мақсаты - жаңа мүмкіндіктерді шығару және бизнестің қажеттіліктерін қанағаттандыру. Ops командасының мақсаты - бәрі жұмыс істейтініне және ештеңе бұзылмайтынына көз жеткізу. Әлбетте, бұл мақсаттар бір-біріне тікелей қайшы келеді: бәрі жұмыс істеп, ештеңе бұзылмауы үшін жаңа мүмкіндіктерді мүмкіндігінше аз шығарыңыз. Осыған байланысты қазір DevOps деп аталатын әдістеме шешуге тырысатын көптеген ішкі қайшылықтар бар.
Мәселе мынада, бізде DevOps-тың нақты анықтамасы және DevOps-тың нақты жүзеге асырылуы жоқ. Мен 2 жыл бұрын Екатеринбургте өткен конференцияда сөз сөйледім, осы уақытқа дейін DevOps бөлімі «DevOps дегеніміз не» баяндамасымен басталды. 2017 жылы Devops 10 жаста, бірақ біз оның не екенін әлі де талқылаймыз. Бұл Google бірнеше жыл бұрын шешуге тырысқан өте оғаш жағдай.
2016 жылы Google сайт сенімділігі инженериясы деп аталатын кітапты шығарды. Ал шын мәнінде, дәл осы кітаппен SRE қозғалысы басталды. SRE - белгілі бір компанияда DevOps парадигмасының нақты іске асырылуы. SRE инженерлері жүйелердің сенімді жұмыс істеуін қамтамасыз етуге міндеттенеді. Олар негізінен әзірлеушілерден, кейде күшті даму тәжірибесі бар әкімшілерден келеді. Және олар бұрын жүйелік әкімшілер жасайтын нәрсені істейді, бірақ код тұрғысынан жүйенің дамуы мен білімі бұл адамдардың әдеттегі әкімшілік жұмысқа бейім емес, автоматтандыруға бейім болуына әкеледі.
SRE командаларындағы DevOps парадигмасы құрылымдық мәселелерді шешетін SRE инженерлерінің болуымен жүзеге асырылады. Міне, адамдар 8 жыл бойы айтып келе жатқан Dev және Ops арасындағы бірдей байланыс. SRE рөлі сәулетшінің рөліне ұқсас, өйткені жаңадан келгендер SRE болмайды. Еңбек жолын бастаған адамдардың әлі тәжірибесі жоқ, қажетті білім кеңдігі жоқ. Өйткені SRE нақты не және қашан қате болуы мүмкін екендігі туралы өте нәзік білімді қажет етеді. Сондықтан мұнда, әдетте, компания ішінде де, сыртында да біраз тәжірибе қажет.
Олар SRE мен devops арасындағы айырмашылық сипатталатынын сұрайды. Ол жай ғана сипатталды. Ұйымдағы СРЖ орны туралы айтуға болады. Ops әлі де жеке бөлім болып табылатын классикалық DevOps тәсілінен айырмашылығы, SRE әзірлеу тобының бөлігі болып табылады. Олар өнімді әзірлеуге қатысады. Тіпті SRE бір әзірлеушіден екіншісіне өтетін рөл болып табылатын тәсіл бар. Олар, мысалы, UX дизайнерлері, әзірлеушілердің өздері, кейде өнім менеджерлері сияқты кодты шолуға қатысады. SRE бірдей деңгейде жұмыс істейді. Біз оларды мақұлдауымыз керек, әрбір орналастыру үшін SRE былай дейді: «Жарайды, бұл орналастыру, бұл өнім сенімділікке теріс әсер етпейді. Ал егер солай болса, онда кейбір қолайлы шектерде. Бұл туралы да айтатын боламыз.
Тиісінше, SRE кодты өзгертуге вето құқығы бар. Жалпы алғанда, егер SRE дұрыс орындалмаса, бұл қандай да бір кішігірім қақтығыстарға әкеледі. Сайттың сенімділік инженериясы туралы сол кітапта көптеген бөліктер, тіпті біреуі де емес, бұл қақтығыстарды қалай болдырмау керектігін айтады.
Олар SRE ақпараттық қауіпсіздікке қалай қатысты екенін сұрайды. SRE ақпараттық қауіпсіздікке тікелей қатысы жоқ. Негізінен ірі компанияларда мұны жеке тұлғалар, тестерлер, талдаушылар жасайды. Бірақ SRE олармен қауіпсіздікке әсер ететін кейбір операциялар, кейбір міндеттемелер, кейбір орналастырулар да өнімнің қолжетімділігіне әсер етуі мүмкін деген мағынада өзара әрекеттеседі. Сондықтан, SRE тұтастай алғанда кез келген командалармен, соның ішінде қауіпсіздік топтарымен, соның ішінде талдаушылармен өзара әрекеттеседі. Сондықтан, SRE негізінен DevOps енгізуге тырысқанда қажет, бірақ сонымен бірге әзірлеушілерге жүктеме тым үлкен болады. Яғни, әзірлеу тобының өзі енді олар да Ops үшін жауапты болуы керек екеніне төтеп бере алмайды. Және бөлек рөл бар. Бұл рөл бюджетте жоспарланған. Кейде бұл рөл команданың мөлшерінде белгіленеді, жеке адам пайда болады, кейде әзірлеушілердің бірі оған айналады. Командада алғашқы SRE осылай пайда болады.
SRE әсер ететін жүйенің күрделілігі, операцияның сенімділігіне әсер ететін күрделілік қажет және кездейсоқ. Қажетті күрделілік - бұл өнімнің күрделілігі жаңа өнімнің ерекшеліктері талап ететін дәрежеде артады. Кездейсоқ күрделілік - бұл жүйенің күрделілігі жоғарылаған кезде, бірақ өнімнің ерекшелігі және бизнес талаптары бұған тікелей әсер етпейді. Әзірлеуші бір жерде қателескен, немесе алгоритм оңтайлы емес, немесе ерекше қажетсіз өнімнің күрделілігін арттыратын кейбір қосымша қызығушылықтар енгізілгені белгілі болды. Жақсы SRE әрқашан бұл жағдайды кесіп тастауы керек. Яғни, кез келген міндеттеме, кез келген орналастыру, кез келген тарту сұрауы, кездейсоқ қосуға байланысты қиындығы артады, бұғатталуы керек.
Мәселе неге командаға инженер, жүйелік әкімшіні үлкен білімі бар жұмысқа алмайсыз. Инженер рөліндегі әзірлеуші, бізге айтылады, кадр мәселесінің ең жақсы шешімі емес. Инженер рөліндегі әзірлеуші әрқашан кадр мәселесінің ең жақсы шешімі бола бермейді, бірақ мұндағы мәселе Ops-пен айналысатын әзірлеушінің автоматтандыруға деген ұмтылысы, аздап көбірек білімі мен дағдылары бар. бұл автоматтандыру. Тиісінше, біз белгілі бір операцияларды орындау уақытын ғана емес, тек күнделікті режимді ғана емес, сонымен қатар MTTR (қалпына келтірудің орташа уақыты, қалпына келтіру уақыты) сияқты маңызды бизнес параметрлерін де қысқартамыз. Осылайша, біз бұл туралы сәл кейінірек айтамыз, біз ұйымға ақша үнемдейміз.
Енді SRE жұмыс істеу критерийлеріне тоқталайық. Және ең алдымен сенімділік туралы. Шағын компанияларда, стартаптарда қызмет жақсы жазылса, өнім жақсы әрі дұрыс жазылса, ол жұмыс істейді, бұзылмайды деп есептейтін жағдайлар жиі кездеседі. Міне, біз жақсы код жазамыз, сондықтан бұзатын ештеңе жоқ. Код өте қарапайым, бұзатын ештеңе жоқ. Бұл бізге сынақтар қажет емес деп айтатын адамдар туралы, өйткені бұл VPI үш әдісі, мұнда неге үзілу керек.
Мұның бәрі дұрыс емес, әрине. Бұл адамдар іс жүзінде мұндай кодты жиі шағып алады, өйткені заттар бұзылады. Істер кейде ең күтпеген жолмен бұзылады. Кейде адамдар жоқ, ол ешқашан болмайды дейді. Және бұл барлық уақытта болады. Бұл жеткілікті жиі болады. Міне, сондықтан ешкім ешқашан 100% қолжетімділікке ұмтылмайды, өйткені 100% қолжетімділік ешқашан болмайды. Бұл норма. Сондықтан біз қызметтің қолжетімділігі туралы айтатын болсақ, біз әрқашан тоғыз туралы айтамыз. 2 тоғыз, 3 тоғыз, 4 тоғыз, 5 тоғыз. Егер біз мұны тоқтап қалуға аударсақ, онда, мысалы, 5 тоғыз, онда бұл жылына 5 минуттан сәл артық, 2 тоғыз - 3,5 күн тоқтап тұру.
Бірақ белгілі бір уақытта POI төмендеуі, инвестицияның қайтарымы байқалатыны анық. Екі тоғыздан үш тоғызға өту тоқтау уақытын 3 күннен артық қысқартады. Төрт тоғыздан беске дейін көтерілу тоқтау уақытын жылына 47 минутқа қысқартады. Ал бизнес үшін бұл сын көтермейтін шығар. Ал жалпы талап етілетін сенімділік техникалық мәселе емес, біріншіден, бұл бизнес мәселесі, бұл өнім мәселесі. Өнімді пайдаланушылар үшін тоқтап қалудың қандай деңгейі қолайлы, олар не күтеді, олар қанша төлейді, мысалы, олар қанша ақша жоғалтады, жүйе қанша ақша жоғалтады.
Мұнда маңызды мәселе - қалған компоненттердің сенімділігі қандай. Өйткені 4 тоғыз сенімділігі бар смартфонда 5 пен 2 тоғыз арасындағы айырмашылық көрінбейді. Шамамен айтқанда, егер сіздің қызметіңізде смартфонда бірдеңе жылына 10 рет бұзылса, ОС жағында 8 рет бұзылған болуы мүмкін. Пайдаланушы бұған үйренген және жылына бір рет назар аудармайды. Сенімділікті арттыру мен пайданы арттыру бағасын корреляциялау қажет.
Тек SRE туралы кітапта 4 тоғыздан 3 тоғызға дейін арттырудың жақсы мысалы бар. Қолжетімділіктің ұлғаюы 0,1%-дан сәл аз болып шықты. Ал егер қызметтен түсетін табыс жылына 1 миллион доллар болса, онда табыстың өсуі 900 долларды құрайды. Қолжетімділікті тоғызға арттыру үшін бізге жылына 900 доллардан аз шығын түссе, ұлғайту қаржылық мағынаға ие болады. Егер ол жылына 900 доллардан асатын болса, бұл енді мағынасы жоқ, өйткені кірістің өсуі жай ғана еңбек шығындарын, ресурс шығындарын өтемейді. Ал бізге 3 тоғыз жетеді.
Бұл, әрине, барлық сұраулар тең болатын жеңілдетілген мысал. Ал 3 тоғыздан 4 тоғызға өту жеткілікті оңай, бірақ сонымен бірге, мысалы, 2 тоғыздан 3-ке өту, бұл қазірдің өзінде 9 мың доллар үнемдеу, бұл қаржылық мағынаға ие болуы мүмкін. Әрине, шын мәнінде, тіркеу сұрауының сәтсіздігі бетті көрсетпеуден де жаман, сұраулардың салмағы әртүрлі. Олар бизнес тұрғысынан мүлдем басқа критерийге ие болуы мүмкін, бірақ бәрібір, әдетте, егер біз кейбір нақты қызметтер туралы айтпасақ, бұл өте сенімді жуықтау.
Бізге сервистің архитектуралық шешімін таңдау кезінде SRE координаторлардың бірі болып табыла ма деген сұрақ алдық. Оның тұрақтылығын жоғалтпау үшін қолданыстағы инфрақұрылымға интеграциялау тұрғысынан айтайық. Иә, SRE, сұрауларды тарту, міндеттеу, шығарылымдар сәулетке, жаңа қызметтерді, микросервистерді енгізуге, жаңа шешімдерді енгізуге әсер етеді. Неліктен тәжірибе керек, біліктілік керек деп бұрын айттым. Шындығында, SRE кез келген архитектуралық және бағдарламалық шешімдегі блоктаушы дауыстардың бірі болып табылады. Тиісінше, инженер ретіндегі SRE, ең алдымен, түсініп қана қоймай, сонымен қатар кейбір нақты шешімдердің сенімділікке, тұрақтылыққа қалай әсер ететінін түсінуі және оның бизнес қажеттіліктеріне қалай қатысты екенін және қандай көзқараспен қолайлы және қолайлы болуы мүмкін екенін түсінуі керек. қайсы емес.
Сондықтан, қазір SRE-де дәстүрлі түрде SLA (қызмет көрсету деңгейі туралы келісім) ретінде анықталған сенімділік критерийлері туралы айтуға болады. Сірә, таныс термин. SLI (қызмет деңгейінің көрсеткіші). SLO (қызмет деңгейінің мақсаты). Қызмет көрсету деңгейінің келісімі символдық термин болуы мүмкін, әсіресе сіз желілермен, провайдерлермен, хостингпен жұмыс істеген болсаңыз. Бұл бүкіл қызметтің өнімділігін, айыппұлдарды, қателер үшін кейбір айыппұлдарды, көрсеткіштерді, критерийлерді сипаттайтын жалпы келісім. Ал SLI – қолжетімділік көрсеткішінің өзі. Яғни, SLI қандай болуы мүмкін: қызметтен жауап беру уақыты, пайызбен қателер саны. Бұл файлды орналастырудың қандай да бір түрі болса, өткізу қабілеттілігі болуы мүмкін. Алгоритмдерді тану туралы айтатын болсақ, көрсеткіш, мысалы, жауаптың дұрыстығы болуы мүмкін. SLO (Service Level Objective) сәйкесінше, SLI көрсеткішінің, оның мәні мен кезеңінің тіркесімі болып табылады.
SLA осындай болуы мүмкін делік. Қызмет жыл бойына 99,95% қолжетімді. Немесе 99 сыни қолдау билеттері тоқсанына 3 сағат ішінде жабылады. Немесе сұраулардың 85%-ына ай сайын 1,5 секунд ішінде жауап беріледі. Яғни, қателіктер мен сәтсіздіктердің қалыпты жағдай екенін бірте-бірте түсінеміз. Бұл қолайлы жағдай, біз оны жоспарлап жатырмыз, тіпті белгілі бір дәрежеде оған сенеміз. Яғни, SRE қате жіберуі мүмкін жүйелерді құрастырады, олар қателерге қалыпты жауап беруі керек, олар ескерілуі керек. Мүмкіндігінше, олар қателерді пайдаланушы оларды байқамайтындай немесе байқамайтындай етіп өңдеуі керек, бірақ бұл мәселені шешудің қандай да бір түрі бар, соның арқасында бәрі толығымен құлап кетпейді.
Мысалы, егер сіз YouTube-ке бейне жүктеп салсаңыз және YouTube оны бірден түрлендіре алмаса, егер бейне тым үлкен болса, формат оңтайлы болмаса, сұрау табиғи түрде күту уақытымен орындалмайды, YouTube 502 қатесін бермейді. , YouTube: «Біз барлығын жасадық, бейнеңіз өңделуде. Ол шамамен 10 минутта дайын болады». Бұл әсем деградация принципі, мысалы, алдыңғы қатарлы әзірлеуден таныс, егер сіз мұны бұрыннан жасаған болсаңыз.
Сенімділікпен, қателермен, күтулермен жұмыс істеу үшін өте маңызды, біз айтатын келесі терминдер - MTBF және MTTR. MTBF – сәтсіздіктер арасындағы орташа уақыт. MTTR Қалпына келтірудің орташа уақыты, қалпына келтіруге дейінгі орташа уақыт. Яғни, қате анықталған сәттен бастап, қате пайда болған сәттен бастап қызмет толық қалыпты жұмыс істеуге дейін қалпына келтірілгенге дейін қанша уақыт өтті. MTBF негізінен код сапасы бойынша жұмыс арқылы бекітіледі. Яғни, СРЕ «жоқ» деп айта алатындығы. Ал СРЭ «жоқ» десе, ол оны зиянды болғандықтан емес, жаман болғандықтан емес, әйтпесе бәрі зардап шегетіндіктен айтатынын бүкіл команданың түсінуі керек.
Тағы да, көптеген мақалалар, көптеген әдістер, көптеген жолдар бар, тіпті мен жиі сілтеме жасайтын кітаптың өзінде, басқа әзірлеушілер SRE-ді жек көрмейтініне қалай көз жеткізуге болады. MTTR, екінші жағынан, сіздің SLO (қызмет деңгейінің мақсаты) бойынша жұмыс істеу туралы. Және бұл негізінен автоматтандыру. Өйткені, мысалы, біздің SLO - тоқсанына 4 тоғыз жұмыс уақыты. Бұл 3 айдың ішінде біз 13 минут тоқтап қалуға жол бере аламыз дегенді білдіреді. Біздің MTTR 13 минуттан артық болуы мүмкін емес екені белгілі болды. Кем дегенде 13 тоқтап тұруға әрекет ету үшін 1 минут кететін болсақ, бұл тоқсандағы бүкіл бюджетті таусылғанымызды білдіреді. Біз SLO бұзамыз. Ақаулыққа әрекет ету және түзету үшін 13 минут - машина үшін көп, бірақ адам үшін өте аз. Өйткені адам ескерту алған кезде, ол әрекет еткен кезде, қатені анықтаған кезде, бұл бірнеше минут. Адам оны қалай түзетуге болатынын, нақты нені түзету керектігін, не істеу керектігін түсінбейінше, бұл тағы бірнеше минутты алады. Шындығында, серверді қайта жүктеу немесе жаңа түйінді көтеру қажет болса да, MTTR қолмен шамамен 7-8 минутты алады. Процесті автоматтандыру кезінде MTTR жиі секундқа, кейде миллисекундқа жетеді. Google әдетте миллисекундтар туралы айтады, бірақ шын мәнінде, әрине, бәрі жақсы емес.
Ең дұрысы, SRE өз жұмысын толығымен дерлік автоматтандыруы керек, өйткені бұл MTTR-ге, оның көрсеткіштеріне, бүкіл қызметтің SLO-сына және сәйкесінше бизнестің пайдасына тікелей әсер етеді. Егер уақыт асып кетсе, бізден SRE кінәлі ме деп сұралады. Бақытымызға орай, ешкім кінәлі емес. Бұл бальзамсыз постмортем деп аталатын бөлек мәдениет, ол туралы біз бүгін айтпаймыз, бірақ біз оны Slurm-да талдаймыз. Бұл өте қызықты тақырып, ол туралы көп айтуға болады. Дөрекі сөзбен айтқанда, тоқсанға берілген уақыт асып кетсе, әркім кінәлі, демек, бәрін кінәлау нәтиже бермейді, оның орнына біреуді кінәламай, жағдайды түзетіп, қолдағы бармен жұмыс істейік. Менің тәжірибемде бұл тәсіл командалардың көпшілігіне, әсіресе Ресейде біршама жат, бірақ ол мағынасы бар және өте жақсы жұмыс істейді. Сондықтан мен мақаланың соңында осы тақырып бойынша оқуға болатын әдебиеттерді ұсынамын. Немесе Slurm SRE-ге келіңіз.
Түсіндірейін. Егер тоқсан сайынғы SLO уақыты асып кетсе, тоқтау уақыты 13 минут емес, 15 минут болса, бұған кім кінәлі болуы мүмкін? Әрине, SRE кінәлі болуы мүмкін, өйткені ол қандай да бір жаман міндеттеме немесе орналастыруды жасады. Бұған дата орталығының әкімшісі кінәлі болуы мүмкін, себебі ол қандай да бір жоспардан тыс техникалық қызмет көрсетуді жүзеге асырған болуы мүмкін. Егер бұған дата орталығының әкімшісі кінәлі болса, бұл үшін SLO-ны үйлестіру кезінде техникалық қызмет көрсетуді есептемеген Оптан келген адам кінәлі. Бұған менеджер, техникалық директор немесе деректер орталығының келісім-шартына қол қойған және деректер орталығының SLA талап етілетін тоқтау уақытына арналмағанына назар аудармаған адам кінәлі. Тиісінше, бұл жағдайдағы барлығы бірте-бірте кінәлі. Ал бұл жағдайда кінәні біреуге артудың қажеті жоқ деген сөз. Бірақ, әрине, оны түзету керек. Сондықтан өлгеннен кейін өлу орындары бар. Егер сіз, мысалы, GitHub постмортемдерін оқысаңыз және бұл әрқашан өте қызықты, шағын және әр жағдайда күтпеген оқиға болса, сіз бұл нақты адам кінәлі деп ешкім ешқашан айтпайтынын ауыстыра аласыз. Кінә әрқашан нақты жетілмеген процестерге жүктеледі.
Келесі сұраққа көшейік. Автоматтандыру. Басқа контексттерде автоматтандыру туралы айтатын болсам, мен көбінесе үнемдегеннен гөрі автоматтандыруға көп уақыт жұмсамай, тапсырманы автоматтандыруда қанша уақыт жұмыс істеуге болатынын көрсететін кестеге сілтеме жасаймын. Қиындық бар. Ең бастысы, SRE тапсырманы автоматтандырғанда, олар уақытты ғана емес, ақшаны да үнемдейді, өйткені автоматтандыру MTTR-ге тікелей әсер етеді. Олар, былайша айтқанда, қызметкерлер мен әзірлеушілердің моральдық деңгейін сақтайды, бұл да сарқылмайтын ресурс. Олар күн тәртібін азайтады. Мұның бәрі жұмысқа және соның нәтижесінде бизнеске оң әсер етеді, тіпті уақыт шығындары тұрғысынан автоматтандыру мағынасы жоқ сияқты көрінсе де.
Шындығында, бұл әрдайым дерлік болады және SRE рөлінде бір нәрсені автоматтандырудың қажеті жоқ жағдайлар өте аз. Әрі қарай біз қателер бюджеті, қателер бюджеті деп аталатын нәрсе туралы сөйлесеміз. Шындығында, егер сіз өзіңіз үшін белгіленген SLO-дан әлдеқайда жақсы жұмыс істеп жатсаңыз, бұл өте жақсы емес. Бұл өте нашар, өйткені SLO тек төменгі шек ретінде ғана емес, сонымен қатар шамамен жоғарғы шекара ретінде де жұмыс істейді. Сіз өзіңізге 99% қолжетімділік SLO орнатқанда және шын мәнінде сізде 99,99% болса, сізде бизнеске мүлдем зиян тигізбейтін тәжірибе үшін бос орын бар екені белгілі болды, өйткені сіз мұның бәрін бірге анықтадыңыз және сіз Бұл кеңістік болса, оны пайдаланбаңыз. Сіздің жағдайыңызда жұмсалмаған қателер үшін бюджетіңіз бар.
Онымен не істейміз. Біз оны барлық нәрсе үшін қолданамыз. Өндіріс жағдайында сынау үшін, өнімділікке әсер етуі мүмкін жаңа мүмкіндіктерді шығару үшін, шығарылымдар үшін, техникалық қызмет көрсету үшін, жоспарланған тоқтаулар үшін. Кері ереже де қолданылады: егер бюджет таусылған болса, біз жаңа ештеңе шығара алмаймыз, өйткені әйтпесе біз SLO-дан асып кетеміз. Бюджет таусылды, егер ол өнімділікке теріс әсер етсе, біз бірдеңе шығардық, яғни бұл өздігінен SLO-ны тікелей арттыратын қандай да бір түзету болмаса, онда біз бюджет шегінен шығып жатырмыз және бұл нашар жағдай. , оны талдау керек, өлгеннен кейін және мүмкін кейбір процестерді түзету керек.
Яғни, егер қызметтің өзі жақсы жұмыс істемесе және SLO жұмсалса және бюджет эксперименттерге емес, кейбір шығарылымдарға емес, өздігінен жұмсалса, қызықты мүмкіндіктердің орнына кейбір қызықты түзетулердің орнына, қызықты шығарылымдардың орнына. Кез келген шығармашылық жұмыстың орнына бюджетті ретке келтіру немесе SLO өңдеу үшін ақымақ түзетулермен айналысуға тура келеді, және бұл да жиі болмайтын процесс.
Сондықтан, қателер үшін бюджетіміз көп болған жағдайда барлығына қызығушылық танытады: SRE де, әзірлеушілер де. Әзірлеушілер үшін қателерге арналған үлкен бюджет шығарылымдармен, сынақтармен, эксперименттермен күресуге болатындығын білдіреді. SRE үшін қателер үшін бюджет және осы бюджетке кіру олардың тікелей өз жұмысын жақсы орындайтынын білдіреді. Және бұл бірлескен жұмыстың қандай да бір түрінің мотивациясына әсер етеді. Егер сіз өзіңіздің SRE-ді әзірлеушілер ретінде тыңдасаңыз, сізде жақсы жұмыс үшін көбірек орын және әлдеқайда аз күнделікті жұмыс болады.
Өндірістегі тәжірибелер үлкен командалардағы SRE-дің айтарлықтай маңызды және дерлік ажырамас бөлігі болып табылады. Бұл әдетте Chaos Monkey деп аталатын қызметтік бағдарламаны шығарған Netflix тобынан шыққан хаос инженериясы деп аталады.
Chaos Monkey CI/CD құбырына қосылып, өндірісте серверді кездейсоқ бұзады. Тағы да, SRE құрылымында біз құлаған сервердің өзі жаман емес, күтілетіні туралы айтып отырмыз. Ал бюджет шегінде болса, ол қолайлы, бизнеске зияны жоқ. Әрине, Netflix-те жеткілікті артық серверлер, жеткілікті репликация бар, мұның барлығын түзетуге болады, және тұтастай алғанда пайдаланушы тіпті байқамайды, тіпті одан да көп ешкім кез келген бюджет үшін бір серверді қалдырмайды.
Біраз уақыттан бері Netflix-те осындай утилиталардың толық жиынтығы болды, олардың бірі Chaos Gorilla Amazon-ның қолжетімділік аймақтарының бірін толығымен өшіреді. Ал мұндай нәрселер, біріншіден, ненің әсер ететіні, ненің не нәрсеге байланысты екені толық түсініксіз болған кезде, жасырын тәуелділіктерді ашуға көмектеседі. Және бұл, егер сіз микросервиспен жұмыс істеп жатсаңыз және құжаттама өте жақсы болмаса, бұл сізге таныс болуы мүмкін. Тағы да, бұл кодтағы қателерді анықтауға көп көмектеседі, оларды сахналау кезінде ұстай алмайсыз, өйткені кез келген сахналау дәл модельдеу емес, себебі жүктеме масштабы әртүрлі, жүктеме үлгісі әртүрлі, жабдық сондай-ақ, ең алдымен, басқа. Ең жоғары жүктемелер күтпеген және күтпеген болуы мүмкін. Және тағы да бюджет шегінен шықпайтын мұндай тестілеу инфрақұрылымдағы қателерді анықтауға өте жақсы көмектеседі, оны қою, автотесттер, CI / CD құбыры ешқашан ұстамайды. Мұның бәрі сіздің бюджетіңізге кіретін болса, сіздің қызметіңіздің төмендегені маңызды емес, бірақ бұл өте қорқынышты болып көрінсе де, сервер істен шықты, бұл қандай қорқынышты. Жоқ, бұл қалыпты жағдай, бұл жақсы, бұл қателерді ұстауға көмектеседі. Егер сізде бюджет болса, оны жұмсауға болады.
Сұрақ: қандай әдебиетті ұсына аламын? Тізім соңында. Әдебиет өте көп, мен бірнеше баяндамаларды ұсынар едім. Бұл қалай жұмыс істейді және SRE жеке бағдарламалық өнімі жоқ немесе ең аз әзірлемелері бар компанияларда жұмыс істей ме. Мысалы, негізгі қызметі бағдарламалық қамтамасыз ету болып табылмайтын кәсіпорында. Негізгі қызметі бағдарламалық қамтамасыз ету болып табылмайтын кәсіпорында SRE кез келген жердегі сияқты жұмыс істейді, өйткені кәсіпорында сіз бағдарламалық жасақтама өнімдерін әзірлемесеңіз де, жаңартуларды шығаруыңыз керек инфрақұрылымды өзгерту керек, өсу керек, масштабтау керек. Ал SRE бұл процестердегі ықтимал проблемаларды анықтауға және болжауға көмектеседі және кейбір өсу басталғаннан кейін және бизнес қажеттіліктері өзгергеннен кейін оларды басқаруға көмектеседі. Өйткені, егер сізде кем дегенде бірнеше серверлер болса және кем дегенде өсуді күтсеңіз, SRE болуы үшін бағдарламалық жасақтаманы әзірлеумен айналысудың қажеті жоқ.
Бұл кішігірім жобаларға, шағын ұйымдарға да қатысты, өйткені ірі компаниялардың бюджеті және тәжірибе жасауға кеңістігі бар. Бірақ сонымен бірге эксперименттердің барлық осы жемістерін кез келген жерде қолдануға болады, яғни SRE, әрине, Google-да, Netflix-те, Dropbox-та пайда болды. Бірақ сонымен бірге шағын компаниялар мен стартаптар жинақталған материалдарды оқи алады, кітаптар оқи алады, есептерді көре алады. Олар бұл туралы жиі ести бастайды, олар нақты мысалдарға қарайды, менің ойымша, бұл жақсы, бұл шынымен де пайдалы болуы мүмкін, бізге де бұл керек, өте жақсы.
Яғни, бұл процестерді стандарттау бойынша барлық негізгі жұмыстар сіз үшін жасалды. Сіздің компанияңыздағы SRE рөлін нақты анықтау және тағы да сипатталған осы тәжірибелердің барлығын іс жүзінде жүзеге асыруға кірісу сізге қалады. Яғни, шағын компаниялар үшін пайдалы принциптерден бұл әрқашан SLA, SLI, SLO анықтамасы. Егер сіз бағдарламалық жасақтамамен айналыспасаңыз, бұл ішкі SLA және ішкі SLO, қателер үшін ішкі бюджет болады. Бұл әрдайым дерлік команда ішінде және бизнес ішінде кейбір қызықты пікірталастарға әкеледі, өйткені сіз инфрақұрылымға, идеалды процестерді ұйымдастыруға жұмсайтыныңыз анықталуы мүмкін, идеалды құбыр қажет болғаннан әлдеқайда көп. Ал сізде IT бөлімінде бар осы 4 тоғыз қазір сізге қажет емес. Бірақ сонымен бірге сіз уақытты жұмсай аласыз, қателіктер үшін бюджетті басқа нәрсеге жұмсай аласыз.
Тиісінше, мониторинг және мониторингті ұйымдастыру кез келген көлемдегі компания үшін пайдалы. Жалпы алғанда, бұл ойлау тәсілі, қателіктер қолайлы, бюджет бар жерде, Мақсаттар бар жерде 3 адамға арналған стартаптардан бастап кез келген көлемдегі компания үшін пайдалы.
Техникалық нюанстардың соңғысы - бұл мониторинг. Өйткені егер біз SLA, SLI, SLO туралы айтатын болсақ, біз бюджетке сәйкес келетін-келмейтінімізді, Мақсаттарымызға сәйкес келетінімізді және соңғы SLA-ға қалай әсер ететінімізді бақыламай-ақ түсіне алмаймыз. Мен бақылаудың осылай болатынын көп рет көрдім: белгілі бір мән бар, мысалы, серверге сұрау уақыты, орташа уақыт немесе дерекқорға сұраулар саны. Оның инженер белгілеген стандарты бар. Көрсеткіш нормадан ауытқыса, электрондық пошта келеді. Мұның бәрі, әдетте, мүлдем пайдасыз, өйткені бұл ескертулердің көптігіне, бақылаудан түсетін хабарламалардың көптігіне әкеледі, бұл кезде адам, ең алдымен, оларды әр уақытта түсіндіруі керек, яғни метрикалық құралдардың мәнін анықтау керек. кейбір әрекеттердің қажеттілігі. Екіншіден, ол одан ешқандай әрекет талап етілмесе, бұл ескертулердің барлығын байқамай қалады. Бұл жақсы бақылау ережесі және SRE іске асырылған кездегі ең бірінші ереже - бұл хабарландыру тек әрекет қажет болғанда ғана келуі керек.
Стандартты жағдайда оқиғалардың 3 деңгейі бар. Ескертулер бар, билеттер бар, журналдар бар. Ескертулер – шұғыл әрекет етуді талап ететін кез келген нәрсе. Яғни, бәрі бұзылған, дәл қазір жөндеу керек. Билеттер кешіктірілген әрекетті қажет етеді. Иә, бірдеңе істеу керек, қолмен бірдеңе жасау керек, автоматтандыру сәтсіз аяқталды, бірақ келесі бірнеше минутта мұны істеудің қажеті жоқ. Журналдар - бұл әрекетті қажет етпейтін кез келген нәрсе, және жалпы алғанда, егер бәрі жақсы болса, оларды ешкім ешқашан оқымайды. Сізге журналдарды оқып шығу керек, егер өткенге қарасақ, біраз уақыт бойы бірдеңе бұзылғаны белгілі болды, біз бұл туралы білмедік. Немесе сізге біраз зерттеу керек пе. Бірақ тұтастай алғанда, ешқандай әрекетті қажет етпейтін барлық нәрсе журналдарға өтеді.
Осының барлығының жанама әсері ретінде, егер қандай оқиғалар әрекеттерді қажет ететінін анықтап, бұл әрекеттердің қандай болуы керектігін жақсы сипаттаған болсақ, бұл әрекетті автоматтандыруға болады дегенді білдіреді. Яғни, не болады. Біз ескертуден шығамыз. Әрекетке көшейік. Біз бұл әрекеттің сипаттамасына барамыз. Содан кейін біз автоматтандыруға көшеміз. Яғни, кез келген автоматтандыру оқиғаға реакциядан басталады.
Мониторингтен біз Бақылау мүмкіндігі деп аталатын терминге көшеміз. Сондай-ақ соңғы бірнеше жылда бұл сөздің айналасында аздап хайп болды. Бұл контекстен тыс нені білдіретінін аз адамдар түсінеді. Бірақ басты мәселе - Бақылау мүмкіндігі жүйенің ашықтығының көрсеткіші болып табылады. Егер бірдеңе дұрыс болмаса, дәл ненің дұрыс еместігін және сол сәтте жүйенің күйін қаншалықты жылдам анықтауға болады. Код тұрғысынан: қандай функция орындалмады, қандай қызмет сәтсіз болды. Қандай күйде болды, мысалы, ішкі айнымалылар, конфигурация. Инфрақұрылымдық тұрғыдан алғанда, бұл қол жетімділік аймағында ақаулық орын алды және егер сізде қандай да бір Kubernetes болса, онда ақаулық қай подкастта орын алды, подкасттың күйі қандай болды. Тиісінше, Observability MTTR-мен тікелей байланыста. Қызметтің бақылау мүмкіндігі неғұрлым жоғары болса, қатені анықтау оңайырақ, қатені түзету оңайырақ, қатені автоматтандыру оңайырақ, MTTR төмен болады.
Шағын компанияларға қайта көшсек, қазірдің өзінде команда мөлшерімен қалай күресуге болады және шағын командаға жеке SRE жалдау қажет пе деген сұрақ жиі кездеседі. Бұл туралы біраз бұрын айтқан. Стартаптың немесе, мысалы, команданың дамуының алғашқы кезеңдерінде бұл мүлдем қажет емес, өйткені SRE өтпелі рөл атқара алады. Және бұл команданы аздап жандандырады, өйткені кем дегенде әртүрлілік бар. Сонымен қатар, ол адамдарды өсумен бірге, жалпы алғанда, SRE жауапкершілігі айтарлықтай өзгеретініне дайындайды. Егер сіз адамды жұмысқа алсаңыз, онда, әрине, оның кейбір үміттері бар. Және бұл күтулер уақыт өте келе өзгермейді, бірақ талаптар өте өзгереді. Сондықтан SRE-ді қалай жалдау ерте кезеңдерде өте қиын. Өзіңізді өсіру әлдеқайда оңай. Бірақ бұл туралы ойлануға тұрарлық.
Жалғыз ерекшелік, мүмкін, өсу үшін өте қатаң және нақты талаптар болған кезде. Яғни, стартап жағдайында бұл инвесторлардың қандай да бір қысымы, бірден бірнеше рет өсу болжамы болуы мүмкін. Содан кейін SRE жалдау негізінен ақталған, себебі оны ақтауға болады. Бізде өсуге талаптар бар, мұндай өсумен ештеңе бұзылмайтынына жауап беретін адам керек.
Тағы бір сұрақ. Әзірлеушілер сынақтардан өтетін, бірақ өндірісті бұзатын, базаны жүктейтін, басқа мүмкіндіктерді бұзатын мүмкіндікті бірнеше рет кесіп тастағанда не істеу керек, қандай процесті жүзеге асыру керек. Тиісінше, бұл жағдайда қателер бюджеті енгізіледі. Ал кейбір қызметтер, кейбір мүмкіндіктер өндірісте сынақтан өтіп жатыр. Бұл канарей болуы мүмкін, пайдаланушылардың аз ғана саны, бірақ қазірдің өзінде өндірісте, мүмкіндік енгізілген кезде, бірақ қазірдің өзінде бірдеңе бұзылса, мысалы, барлық пайдаланушылардың жарты пайызы үшін ол әлі де талапқа сай болады деп күтумен. қателер үшін бюджет. Тиісінше, иә, қате болады, кейбір пайдаланушылар үшін бәрі бұзылады, бірақ біз бұл қалыпты жағдай екенін айттық.
SRE құралдары туралы сұрақ туындады. Яғни, SRE пайдаланатын, басқалар пайдаланбайтын нәрсе бар ма? Шындығында, жоғары мамандандырылған утилиталар бар, мысалы, жүктемелерді имитациялайтын немесе канариялық A / B тестімен айналысатын бағдарламалық жасақтаманың қандай да бір түрі бар. Бірақ негізінен SRE құралдар жинағы сіздің әзірлеушілеріңіз пайдаланып жатыр. Өйткені SRE әзірлеу тобымен тікелей әрекеттеседі. Ал егер сізде әртүрлі құралдар болса, синхрондау үшін уақыт қажет екені белгілі болады. Әсіресе, егер SRE үлкен командаларда, бірнеше команда болуы мүмкін ірі компанияларда жұмыс істесе, бұл жерде компанияның жалпы стандарттауы көп көмектеседі, өйткені 50 командада 50 түрлі утилиталар пайдаланылса, бұл SRE оларды білуі керек дегенді білдіреді. барлық. Және бұл, әрине, ешқашан болмайды. Ал жұмыс сапасы, кем дегенде кейбір бригадалардың бақылау сапасы айтарлықтай төмендейді.
Біздің вебинар аяқталуға жақын. Мен кейбір негізгі нәрселерді айта алдым. Әрине, бір сағатта SRE туралы ештеңе айтып, түсіну мүмкін емес. Бірақ мен осы ойды, негізгі түйінді ойларды жеткізе алдым деп үміттенемін. Содан кейін, егер қызығушылық танытса, тақырыпты тереңірек ашуға, өз бетінше үйренуге, оны басқа адамдар, басқа компанияларда қалай жүзеге асырып жатқанын қарауға болады. Сәйкесінше, ақпан айының басында бізге Slurm SRE-ге келіңіз.
Slurm SRE - бұл үш күндік қарқынды курс, ол мен қазір айтып жатқан нәрсе туралы айтады, бірақ әлдеқайда тереңірек, нақты жағдайлармен, практикамен, бүкіл қарқынды практикалық жұмысқа бағытталған. Адамдар командаларға бөлінеді. Барлығыңыз нақты істермен жұмыс жасайсыз. Сәйкесінше, бізде Booking.com нұсқаушылары Иван Круглов пен Бен Тайлер бар. Бізде Google-дан, Сан-Францискодан келген тамаша Евгений Бараббас бар. Мен де саған бірдеңе айтайын. Сондықтан бізге міндетті түрде келіңіз.
Сонымен, библиография. SRE бойынша сілтемелер бар. сол кітапта, дәлірек айтқанда, Google жазған SRE туралы 2 кітапта. Тағы бір , мұнда шарттар мен олардың қолданылуы біршама егжей-тегжейлі. Келесі 3 түрлі компаниялардағы SRE туралы есептер. Бірінші - , бұл Google компаниясының Бен Тренерінің негізгі баяндамасы. Екінші - . Үшіншісі тағы . Төртінші есеп , оның 5 елінде тек 190 негізгі SRE қызметкері бар. Мұның бәрін қарау өте қызық, өйткені DevOps әртүрлі компанияларға және тіпті әртүрлі командаларға мүлде басқа нәрселерді білдіретіні сияқты, SRE тіпті ұқсас көлемдегі компанияларда да мүлде басқаша жауапкершіліктерге ие.
Хаос инженериясының принциптері бойынша тағы 2 сілтеме: , . Соңында керемет тізімдер сериясынан 3 тізім бар , шамамен және туралы . SRE тізімі өте үлкен, оның бәрін қарап шығудың қажеті жоқ, шамамен 200 мақала бар. Мен сол жерден сыйымдылықты жоспарлау және өлімнен кейінгі кінәратсыз туралы мақалаларды ұсынамын.
Қызықты мақала:
Осы уақыт бойы мені тыңдағаныңыз үшін рахмет. Сіз бірдеңе үйрендіңіз деп үміттенемін. Сізде көбірек білу үшін жеткілікті материал бар деп үміттенемін. Ал кездескенше. Ақпан айында.
Вебинарды Эдуард Медведев жүргізді.
PS: оқуды ұнататындар үшін Эдуард әдебиеттер тізімін берді. Іс жүзінде түсінгісі келетіндер қабылданады .
Ақпарат көзі: www.habr.com