Вебинардын аудиосу начар болгондуктан, биз аны транскрипциялап койдук.
Менин атым Медведев Эдуард. Бүгүн мен SRE деген эмне, SRE кантип пайда болгон, SRE инженерлери кандай иш критерийлери бар, ишенимдүүлүк критерийлери жөнүндө, бир аз анын мониторинги жөнүндө сүйлөшөм. Биз чокуларга чыгабыз, анткени бир сааттын ичинде көп нерсени айта албайсыз, бирок мен кошумча карап чыгуу үчүн материалдарды берем, биз баарыбыз сени күтөбүз . январь айынын аягында Москвада.
Биринчиден, SRE деген эмне жөнүндө сүйлөшөлү - Сайттын ишенимдүүлүгү инженериясы. Анан кантип өзүнчө позиция, өзүнчө багыт катары пайда болду. Мунун баары салттуу өнүгүү чөйрөлөрүндө Dev жана 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 ортосундагы айырмачылык сүрөттөлөбү деп сурашат. Ал жөн эле сүрөттөлгөн. Уюмдагы СРЭнин орду жөнүндө айтсак болот. Бул классикалык DevOps ыкмасынан айырмаланып, анда Ops дагы эле өзүнчө бөлүм болуп саналат, SRE иштеп чыгуу тобунун бир бөлүгү болуп саналат. Алар продукцияны иштеп чыгууга катышат. Ал тургай, SRE бир иштеп чыгуучудан экинчисине өтүүчү роль болгон мамиле бар. Алар, мисалы, UX дизайнерлери, иштеп чыгуучулардын өздөрү, кээде продукт менеджерлери сыяктуу эле кодду карап чыгууга катышат. SREлер бирдей деңгээлде иштешет. Биз аларды бекитишибиз керек, аларды карап чыгышыбыз керек, ар бир жайылтуу үчүн SRE мындай дейт: “Макул, бул жайгаштыруу, бул продукт ишенимдүүлүккө терс таасирин тийгизбейт. Ал эми ошондой болсо, анда кээ бир алгылыктуу чектерде. Бул тууралуу да сүйлөшөбүз.
Ошого ылайык, СРЕ кодексти өзгөртүүгө вето укугуна ээ. Ал эми жалпысынан алганда, бул SRE туура эмес ишке ашырылса, кандайдыр бир майда чыр-чатакка алып келет. Сайттын ишенимдүүлүк инженериясы жөнүндө бир эле китепте көптөгөн бөлүктөрү, атүгүл бирөөсү да, бул чыр-чатактарды кантип болтурбоо керектигин айтат.
Алар SREнин маалымат коопсуздугу менен кандай байланышы бар деп сурашат. SRE маалымат коопсуздугуна түздөн-түз тиешеси жок. Негизинен ири компанияларда муну жеке адамдар, тестерлер, аналитиктер жасашат. Бирок SRE алар менен коопсуздукка таасир этүүчү кээ бир операциялар, кээ бир милдеттенмелер, кээ бир жайгаштыруулар продуктунун жеткиликтүүлүгүнө да таасир этиши мүмкүн деген мааниде иштешет. Ошондуктан, SRE жалпысынан ар кандай командалар, анын ичинде коопсуздук топтору, анын ичинде аналитиктер менен өз ара аракеттенет. Ошондуктан, SREлер негизинен DevOpsти ишке ашырууга аракет кылып жатканда керек, бирок ошол эле учурда иштеп чыгуучуларга жүк өтө чоң болуп калат. Башкача айтканда, иштеп чыгуу тобунун өзү эми алар да Ops үчүн жооп бериши керек экенин көтөрө албайт. Анан өзүнчө ролу бар. Бул ролу бюджетте пландаштырылган. Кээде бул ролу команданын өлчөмү менен белгиленет, өзүнчө адам пайда болот, кээде иштеп чыгуучулардын бири болуп калат. Командада биринчи SRE ушундайча пайда болот.
SRE таасир эткен системанын татаалдыгы, операциянын ишенимдүүлүгүнө таасир этүүчү татаалдык зарыл жана кокустук. Зарыл татаалдык - бул продуктунун татаалдыгы жаңы продукт өзгөчөлүктөрү талап кылынган даражада көбөйөт. Кокус татаалдык - бул системанын татаалдыгы күчөгөндө, бирок продукттун өзгөчөлүгү жана бизнес талаптары буга түздөн-түз таасирин тийгизбейт. Көрсө, же иштеп чыгуучу бир жерден ката кетирген, же алгоритми оптималдуу эмес, же өзгөчө муктаждыксыз буюмдун татаалдыгын арттырган кошумча кызыкчылыктар киргизилет экен. Жакшы SRE дайыма бул жагдайды кесип керек. Башкача айтканда, кокус кошуудан улам кыйынчылык көбөйгөн ар кандай милдеттенме, жайылтуу, тартуу өтүнүчү бөгөттөлүшү керек.
Суроо, эмне үчүн жөн гана инженерди, командага көп билими бар системалык администраторду жумушка албайт. Инженердин ролун иштеп чыгуучу, бизге айтышат, кадр маселеси боюнча эң жакшы чечим эмес. Инженердин ролун иштеп чыгуучу дайыма эле мыкты кадрдык чечим боло бербейт, бирок бул жерде негизги нерсе Оп менен алектенген иштеп чыгуучунун автоматташтырууга бир аз көбүрөөк каалоосу, бир аз көбүрөөк билими жана жөндөмү бар. бул автоматташтыруу. Ошого жараша, биз кээ бир конкреттүү операциялар үчүн убакытты гана эмес, күнүмдүк гана эмес, ошондой эле MTTR (Калыбына келүү үчүн орточо убакыт, калыбына келтирүү убактысы) сыяктуу маанилүү бизнес параметрлерин кыскартабыз. Ошентип, биз дагы бул тууралуу бир аз кийинчерээк сүйлөшөбүз, биз уюштуруу үчүн акча үнөмдөйбүз.
Эми СРЭнин иштөө критерийлерине токтоло кетели. Ал эми биринчи кезекте ишенимдүүлүк жөнүндө. Чакан компанияларда, стартаптарда кызмат жакшы жазылса, продукт жакшы жана туура жазылса иштейт, бузулбайт деп ойлогон учурлар көп кездешет. Болду, биз жакшы код жазабыз, андыктан бузула турган эч нерсе жок. Код абдан жөнөкөй, бузула турган эч нерсе жок. Булар бизге тесттердин кереги жок деп айткан адамдар жөнүндө, анткени, бул үч 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 негизинен коддун сапаты боюнча иш менен аныкталат. Башкача айтканда, SREs "жок" деп айта алат. Ал эми СРЭ "жок" десе, ал зыяндуу болгондугу үчүн эмес, жаман болгону үчүн эмес, антпесе ар бир адам жапа чеккени үчүн айтып жатканын бүт команда түшүнүшү керек.
Дагы бир жолу, көптөгөн макалалар, көптөгөн ыкмалар, көптөгөн жолдор бар, ал тургай, мен көп кайрылган китепте, башка иштеп чыгуучулар SREди жек көрө баштабашы үчүн кантип ынануу керек. MTTR, экинчи жагынан, сиздин SLO (кызмат деңгээлинин максаты) үстүндө иштөө жөнүндө. Жана бул көбүнчө автоматташтыруу. Анткени, мисалы, биздин SLO кварталына 4 тогуздун иштөө убактысы. Бул 3 айдын ичинде биз 13 мүнөт токтоп калууга жол бере алабыз дегенди билдирет. Ал эми MTTR 13 мүнөттөн ашык болушу мүмкүн эмес экен. Эгерде биз 13 мүнөттүн ичинде жок дегенде 1 токтоп калууга жооп берсек, бул биз кварталдын бюджетин толугу менен түгөттүк дегенди билдирет. Биз SLOну бузуп жатабыз. Кырсыкка реакция кылуу жана оңдоо үчүн 13 мүнөт машина үчүн көп, бирок адам үчүн өтө кыска. Анткени адам эскертүү алганга чейин, реакция кылганга чейин, катаны түшүнгүчө, бул бир нече мүнөт. Адам аны кантип оңдоону, эмнени так оңдоону, эмне кылууну түшүнгүчө, бул дагы бир нече мүнөт. Чындыгында, сиз жөн гана серверди өчүрүп күйгүзүшүңүз керек болсо дагы, же жаңы түйүндү көтөрүшүңүз керек болсо, анда кол менен MTTR 7-8 мүнөткө созулат. Процессти автоматташтырууда MTTR көбүнчө секундага, кээде миллисекундга жетет. Google адатта миллисекунддор жөнүндө сүйлөйт, бирок чындыгында, албетте, баары анчалык деле жакшы эмес.
Идеалында, SRE өз ишин дээрлик толугу менен автоматташтырышы керек, анткени бул түздөн-түз MTTRге, анын метрикасына, бүткүл кызматтын SLOсуна жана, демек, бизнестин кирешесине түздөн-түз таасирин тийгизет. Эгерде убакыт өтүп кетсе, бизден SRE күнөөлүүбү деп суралат. Бактыга жараша, эч ким күнөөлүү эмес. Ал эми бул өзүнчө маданият, биз бүгүн сөз кылбайбыз, бирок Слурмда талдайбыз. Бул абдан кызыктуу тема, аны көп сөз кылууга болот. Орой айтканда, кварталга берилген убакыт ашып кетсе, анда бир аздан ар ким күнөөлүү, демек, ар кимди күнөөлөгөн жемиштүү эмес, анын ордуна, балким, бирөөнү күнөөлөбөй, абалды оңдоп, колубузда болгон менен иштейли. Менин тажрыйбам боюнча, бул ыкма көпчүлүк командалар үчүн бир аз жат, айрыкча Россияда, бирок бул мааниси жана абдан жакшы иштейт. Ошондуктан, мен макаланын жана адабияттын аягында бул тема боюнча окууга болот деп сунуш кылам. Же Slurm SREге келиңиз.
Мен түшүндүрүп берейин. Эгерде кварталдагы SLO убактысы ашып кетсе, токтоп калуу 13 мүнөт эмес, 15 мүнөт болсо, буга ким күнөөлүү болушу мүмкүн? Албетте, SRE күнөөлүү болушу мүмкүн, анткени ал кандайдыр бир жаман милдеттенмелерди же жайылтууларды жасаган. Буга дата борборунун администратору күнөөлүү болушу мүмкүн, анткени ал кандайдыр бир пландан тышкаркы тейлөө иштерин жүргүзгөн болушу мүмкүн. Буга дата-борбордун администратору күнөөлүү болсо, анда бул үчүн СЛОну координациялоодо тейлөөнү эсептебеген Опстан адам күнөөлүү. Менеджер, техникалык директор же маалымат борборунун келишимине кол койгон жана дата борборунун SLA талап кылынган токтоп калууга ылайыкташкан эмес экенине көңүл бурбаган адам буга күнөөлүү. Демек, бул кырдаалда акырындык менен баары күнөөлүү. Анан бул кырдаалда бирөөнү күнөөлөгөндөн пайда жок дегенди билдирет. Бирок, албетте, аны оңдоо керек. Ошон үчүн өлүмдөн кийинкилер бар. Эгер сиз, мисалы, GitHub постмортемдерин окусаңыз жана бул ар бир учурда абдан кызыктуу, кичинекей жана күтүлбөгөн окуя болсо, анда эч ким эч качан бул адам күнөөлүү деп айтпаганын алмаштыра аласыз. Күнөө дайыма белгилүү бир кемчиликсиз процесстерге жүктөлөт.
Келгиле, кийинки суроого өтөбүз. Автоматташтыруу. Башка контексттерде автоматташтыруу жөнүндө сөз кылганда, мен көбүнчө сиз үнөмдөгөнгө караганда, автоматташтыруу үчүн көп убакыт талап кылбастан, ишти автоматташтыруу боюнча канча убакыт иштей аларыңызды айткан таблицага кайрылам. Укмуш бар. Баса турган нерсе, SREлер тапшырманы автоматташтырганда, алар убакытты гана үнөмдөбөстөн, акчаны да үнөмдөйт, анткени автоматташтыруу МТТРге түздөн-түз таасирин тийгизет. Алар, мындайча айтканда, кызматкерлердин жана иштеп чыгуучулардын моралдык маанайын сактап калышат, бул да түгөнгүс ресурс. Алар күн тартибин азайтат. Мына ушулардын бардыгы жумушка жана натыйжада бизнеске оң таасирин тийгизет, ал тургай, автоматташтыруу убакытты талап кылуу жагынан мааниси жоктой сезилет.
Чынында, бул дээрлик дайыма бар, жана SRE ролунда бир нерсе автоматташтырылбашы керек болгон учурлар өтө аз. Кийинки ката бюджети, каталар үчүн бюджет деп аталган нерсе жөнүндө сүйлөшөбүз. Чындыгында, эгер сиз өзүңүз үчүн койгон SLOга караганда баары сиз үчүн жакшыраак болсо, бул да жакшы эмес. Бул өтө жаман, анткени SLO төмөнкү гана эмес, ошондой эле болжолдуу жогорку чек катары иштейт. Сиз өзүңүзгө SLO 99% жеткиликтүүлүгүн койгондо жана чындыгында сизде 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 шилтемелер: , . Ал эми аягында Awesome Liists сериясынан 3 тизме бар жөнүндө жана . SRE боюнча тизме укмуштуудай зор, мунун баарын карап чыгуунун кажети жок, 200гө жакын макала бар. Мен ал жерден потенциалды пландаштыруу жана кынтыксыз өлүмдөн кийинки макалаларды сунуштайм.
Кызыктуу макала:
Ушунча убакыт мени укканыңыз үчүн рахмат. Сиз бир нерсе үйрөндүңүз деп үмүттөнөм. Сиз дагы көбүрөөк билүү үчүн жетиштүү материал бар деп үмүттөнөм. Жана көрүшкөнчө. Буюрса февраль айында.
Вебинарды Эдуард Медведев алып барды.
PS: окууну жакшы көргөндөр үчүн Эдуард шилтемелердин тизмесин берди. Иш жүзүндө түшүнүүнү каалагандар кабыл алынат .
Source: www.habr.com