Салам, Хабр! Мен он жылдан бери Highload IT системаларын колдоп келем. Мен бул макалада nginxти 1000+ RPS режиминде иштөө үчүн орнотуу көйгөйлөрү же башка техникалык нерселер жөнүндө жазбайм. Мен мындай системаларды колдоодо жана иштетүүдө пайда болгон процесстердеги көйгөйлөр жөнүндө өз байкоолорум менен бөлүшөм.
Мониторинг
Техникалык колдоо "Эмне үчүн... сайт кайра иштебей жатат?" деген мазмундагы суроо-талап келгенге чейин күтпөйт. Сайт бузулгандан кийин бир мүнөттүн ичинде колдоо көйгөйдү көрүп, аны чече башташы керек. Бирок сайт айсбергдин учу болуп саналат. Анын жеткиликтүүлүгү биринчилерден болуп көзөмөлдөнөт.
Интернет-дүкөндүн калган товарлары ERP тутумунан келбей калганда эмне кылуу керек? Же кардарлар үчүн арзандатууларды эсептеген CRM системасы жооп бербей калдыбы? Сайт иштеп жатат окшойт. Шарттуу Zabbix анын 200 жообун алат. Дежурный нөөмөт мониторингден эч кандай эскертме алган эмес жана "Тактылар оюндарынын" жаңы сезонунун биринчи эпизодун кубаныч менен көрүп жатат.
Мониторинг көбүнчө эс тутумдун абалын, оперативдүү эстутумун жана сервер процессорунун жүгүн өлчөө менен гана чектелет. Бирок бизнес үчүн веб-сайтта продуктунун жеткиликтүүлүгүн алуу алда канча маанилүү. Кластердеги бир виртуалдык машинанын шарттуу иштебей калышы трафиктин ага барбай калышына жана башка серверлерге жүктөмдүн көбөйүшүнө алып келет. Компания акчасын жоготпойт.
Ошондуктан, серверлердеги операциялык системалардын техникалык параметрлерин көзөмөлдөөдөн тышкары, бизнес-метрикаларды конфигурациялашыңыз керек. Акчага түздөн-түз таасир этүүчү көрсөткүчтөр. Тышкы системалар менен ар кандай өз ара аракеттенүү (CRM, ERP жана башкалар). Белгилүү бир убакытка буйрутмалардын саны. Ийгиликтүү же ийгиликсиз кардар авторизациялары жана башка көрсөткүчтөр.
Тышкы системалар менен өз ара аракеттенүү
Ар кандай веб-сайт же мобилдик тиркеме жылдык жүгүртүүсү миллиард рублдан ашкан тышкы системалар менен өз ара аракеттенет. Жогоруда айтылган CRM жана ERPден баштап, сатып алууларды талдоо жана кардарга ал сөзсүз сатып ала турган продуктуну сунуштоо үчүн тышкы Big Data системасына сатуу маалыматтарын өткөрүү менен аяктайт (чындыгында эмес). Ар бир мындай система өзүнүн колдоосуна ээ. Жана көбүнчө бул системалар менен байланыш ооруну жаратат. Айрыкча, көйгөй глобалдуу болгондо жана аны ар кандай системаларда талдоо керек.
Кээ бир системалар администраторлору үчүн телефон номерин же телеграмманы беришет. Кайсы бир жерде сиз менеджерлерге кат жазышыңыз керек же бул тышкы системалардын мүчүлүштүктөрдү көзөмөлдөөчүлөрүнө барышыңыз керек. Ал тургай, бир чоң компаниянын алкагында, ар кандай системалар көп учурда ар кандай колдонмо эсепке алуу системаларында иштейт. Кээде колдонмонун абалын көзөмөлдөө мүмкүн эмес болуп калат. Сиз бир шарттуу Jira өтүнүчүн аласыз. Анан бул биринчи Жиранын комментарийинде сиз башка Жирадагы маселенин шилтемесин койдуңуз. Тиркемеде экинчи Жирада кимдир бирөө буга чейин комментарий жазып жатат маселени чечүү үчүн шарттуу админ Андрейге чалышыңыз керек. Ал эми чындыгында андай эмес.
Бул маселенин эң жакшы чечими, мисалы, Slackте баарлашуу үчүн бирдиктүү мейкиндикти түзүү болмок. Тышкы системаларды иштетүү процессинин бардык катышуучуларын кошулууга чакыруу. Жана ошондой эле тиркемелерди кайталабоо үчүн бир трекер. Тиркемелерди көзөмөлдөө эскертмелеринен баштап, келечекте мүчүлүштүктөрдү чечүүнүн чыгышына чейин бир жерден көзөмөлдөнүшү керек. Сиз муну реалдуу эмес деп айтасыз жана тарыхта биз бир трекерде иштейбиз, алар башкасында иштешет. Ар кандай системалар пайда болуп, алардын өз алдынча IT командалары болгон. Мен макулмун, ошондуктан маселени жогорудан CIO же продукт ээси деңгээлинде чечүү керек.
Сиз өз ара аракеттенген ар бир система көйгөйлөрдү артыкчылыктуу чечүү үчүн так SLA менен кызмат катары колдоо көрсөтүшү керек. Ал эми шарттуу админ Андрей сиз үчүн мүнөт болгондо эмес.
Блокнока адам
Долбоордо (же продуктыда) ар бир адам эс алууга чыгып, жетекчилеринин арасында конвульсияларды пайда кылган адам барбы? Бул devops инженери, аналитик же иштеп чыгуучу болушу мүмкүн. Анткени, кайсы серверлерде кайсы контейнерлер орнотулганын, көйгөй жаралса контейнерди кантип кайра жүктөө керек экенин жана жалпысынан кандайдыр бир татаал маселени ансыз чечүү мүмкүн эмес экенин devops инженери гана билет. Сиздин татаал механизмиңиз кандай иштээрин бир гана аналитик билет. Кайсы маалымат агымдары кайда барат. Кайсы кызматтарга суроо-талаптардын кандай параметрлери боюнча, кайсынысына жооп алабыз.
Журналдарда эмне үчүн каталар бар экенин ким тез түшүнөт жана продукттун олуттуу мүчүлүштүктөрүн тез арада оңдой алат? Албетте, ошол эле иштеп чыгуучу. Башкалар да бар, бирок эмнегедир ал гана системанын ар кандай модулдары кандай иштешин түшүнөт.
Бул көйгөйдүн түпкү себеби документтин жоктугунда. Анткени, эгерде сиздин тутумуңуздун бардык кызматтары сүрөттөлсө, анда аналитиксиз эле көйгөй менен күрөшүүгө болот. Эгерде devops өзүнүн бош графигинен бир нече күн чыгып, бардык серверлерди, кызматтарды жана типтүү көйгөйлөрдү чечүү боюнча нускамаларды сүрөттөп берсе, анда ал жокто көйгөй ансыз деле чечилмек. Көйгөйдү чечүү үчүн эс алууда жээкте сыраны тез бүтүрүп, wi-fi издөөнүн кереги жок.
Жардам берүүчү кызматкерлердин компетенттүүлүгү жана жоопкерчилиги
Ири долбоорлордо компаниялар иштеп чыгуучулардын эмгек акысын үнөмдөшпөйт. Алар ушуга окшош долбоорлордон кымбат орто же улгайган адамдарды издеп жатышат. Колдоо менен кырдаал бир аз башкача. Бул чыгымдарды ар тараптан кыскартууга аракеттенип жатышат. Компаниялар кечээки арзан Enikey жумушчуларын жалдап, тайманбастык менен согушка киришет. Бул стратегия, эгерде биз Зеленограддагы заводдун визиттик картасынын веб-сайты жөнүндө сөз кыла турган болсок, мүмкүн.
Эгерде биз чоң интернет-дүкөн жөнүндө сөз кыла турган болсок, анда токтоп калган ар бир саат Enikey администраторунун айлык маянасына караганда кымбат турат. Баштапкы пункт катары жылдык товар жүгүртүүнүн 1 миллиард рублин алалы. Бул рейтингден каалаган онлайн дүкөндүн минималдуу жүгүртүүсү . Бул сумманы жылына сааттардын санына бөлүп, 100 000 рублдан ашык таза жоготууларды алыңыз. Ал эми түнкү сааттарды эсептебесеңиз, анда сумманы эки эсеге көбөйтсөңүз болот.
Бирок акча негизги нерсе эмес, туурабы? (жок, албетте, эң негизгиси) Аброюнун жоготуулары да бар. Белгилүү интернет-дүкөндүн кулашы социалдык тармактардагы сын-пикирлердин толкунун да, тематикалык медиадагы басылмаларды да жаратышы мүмкүн. Ал эми ашканадагы достордун “ал жерден эч нерсе сатып алба, алардын веб-сайты дайыма иштебей турат” стилиндеги сүйлөшүүсүн такыр өлчөөгө болбойт.
Эми жоопкерчилик. Менин практикамда нөөмөтчү администратор сайттын жеткиликтүү эместиги тууралуу мониторинг системасынын билдирүүсүнө өз убагында жооп бербеген учур болгон. Жайдын жагымдуу жума күнү кечинде Москвадагы белгилүү интернет-дүкөндүн сайты тынч жатты. Ишемби күнү эртең менен бул сайттын продукт менеджери сайт эмне үчүн ачылбай калганын түшүнгөн жок жана Slack'те колдоо жана шашылыш билдирүү чаттарында жымжырттык өкүм сүрдү. Мындай жаңылыштык бизге алты цифралык чыгымга учурады, ал эми бул нөөмөтчү өзүнүн жумушу.
Жоопкерчилик - бул өнүктүрүү үчүн кыйын жөндөм. Адамда бар же жок. Ошондуктан, интервью учурунда анын бар экенин ар кандай суроолор менен аныктоого аракет кылам, алар адам жоопкерчиликти өзүнө алууга көнгөнбү, кыйыр түрдө көрсөтөт. Эгер адам ата-энесинин айтканы үчүн университетти тандадым же аялым айлык маянасы аз деп жумушун алмаштырды деп жооп берсе, анда андай адамдар менен аралашпай эле койгон оң.
Өнүктүрүү тобу менен өз ара аракеттенүү
Колдонуучулар продукт менен иштөөдө жөнөкөй көйгөйлөргө туш болгондо, колдоо аларды өз алдынча чечет. Маселени кайра чыгарууга аракет кылат, журналдарды талдайт ж.б.у.с. Бирок буюмда ката пайда болгондо эмне кылуу керек? Бул учурда, колдоо иштеп чыгуучуларга тапшырма берет жана бул жерде кызыктуу башталат.
Иштеп чыгуучулар дайыма ашыкча жүктөлөт. Алар жаңы функцияларды жаратууда. Сатуу менен мүчүлүштүктөрдү оңдоо эң кызыктуу иш эмес. Кийинки спринтти аяктоо мөөнөтү жакындап калды. Анан колдоодон жагымсыз адамдар келип: "Баарын дароо ташта, бизде көйгөйлөр бар" деп айтышат. Мындай милдеттердин артыкчылыгы минималдуу. Айрыкча, көйгөй эң маанилүү болбогондо жана сайттын негизги функционалдуулугу иштегенде, жана релиз менеджери көздөрү томпоюп чуркап кетпей, мындай деп жазыңыз: "Бул тапшырманы кийинки релизге же оңдоого шашылыш түрдө кошуңуз."
Кадимки же төмөн артыкчылыктуу маселелер чыгарылыштан чыгарууга жылдырылат. “Тапшырма качан бүтөт?” деген суроого сиз төмөнкүдөй стилдеги жоопторду аласыз: "Кечиресиз, азыр тапшырмалар көп, командаңыздын лидерлеринен сураңыз же менеджерден чыгарыңыз."
Өндүрүмдүүлүк көйгөйлөрү жаңы функцияларды жаратууга караганда көбүрөөк артыкчылыкка ээ. Колдонуучулар дайыма мүчүлүштүктөрдү көрүп калышса, жаман сын-пикирлер көпкө созулбайт. Бузулган репутацияны калыбына келтирүү кыйын.
Өнүктүрүү жана колдоо ортосундагы өз ара аракеттенүү маселелери DevOps тарабынан чечилет. Бул аббревиатура көбүнчө иштеп чыгуу үчүн сыноо чөйрөсүн түзүүгө, CICD түтүктөрүн курууга жана сыноодон өткөн кодду өндүрүшкө тез алып чыгууга жардам берген белгилүү бир адам түрүндө колдонулат. DevOps бул процесстин бардык катышуучулары бири-бири менен тыгыз байланышта болуп, программалык камсыздоо өнүмдөрү менен кызматтарын тез түзүүгө жана жаңыртууга жардам бергенде программалык камсыздоону иштеп чыгууга болгон мамиле. Мен аналитиктерди, иштеп чыгуучуларды, тестерлерди жана колдоону билдирет.
Мындай мамиледе колдоо жана өнүктүрүү өз максаттары жана милдеттери бар ар кандай бөлүмдөр эмес. Иштеп чыгуу операцияга катышат жана тескерисинче. Бөлүштүрүлгөн командалардын белгилүү фразасы: "Маселе мен тарапта эмес" деген сөз чаттарда көп кездешпейт жана акыркы колдонуучулар бир аз бактылуураак болушат.
Source: www.habr.com