Белгилүү болгондой, КТОнун компетенттүүлүгү ал бул кызматты экинчи жолу аткарганда гана текшерилет. Анткени компанияда бир нече жыл иштеп, аны менен бирге өнүгүп, ошол эле маданий контекстте болуу менен бара-бара көбүрөөк жоопкерчилик алуу бир нерсе. Ал эми эски жүгү жана килемдин астына шыпырылып жаткан бир топ көйгөйлөрү бар компаниянын техникалык директорунун кызматына түз эле келүү таптакыр башка нерсе.

Бул жагынан алганда, ал бөлүштү Леон Fire тажрыйбасы DevOpsConf, так уникалдуу эмес, бирок анын тажрыйбасы жана 20 жылдын ичинде сынап көрүүгө жетишкен ар кандай ролдордун саны менен көбөйгөн, бул абдан пайдалуу. Төмөндө 90 күндүн ичинде болгон окуялардын хронологиясы жана башка бирөө менен болгондо күлкүгө жарай турган, бирок бетме-бет бетме-бет көрүү анчалык деле кызыктуу болбогон көптөгөн окуялар бар.

Леон орус тилинде абдан кооз сүйлөйт, ошондуктан 35-40 мүнөт болсо, мен видеону көрүүнү сунуштайм. Төмөндө убакытты үнөмдөө үчүн текст версиясы.

Отчеттун биринчи версиясы пайдалуу сунуштарды камтыган адамдар жана процесстер менен иштөөнүн жакшы структураланган сыпаттамасы болгон. Бирок ал жолдо кездешкен бардык сюрприздерди айткан жок. Ошондуктан, мен форматты өзгөртүп, жаңы компанияда менин алдымда пайда болгон көйгөйлөрдү жана аларды чечүүнүн ыкмаларын хронологиялык тартипте сунуштадым.

Бир ай мурун

Көптөгөн жакшы окуялар сыяктуу эле, бул да алкоголдон башталган. Биз достор менен барда отурганбыз, IT адистери күткөндөй, ар кимиси өз көйгөйлөрүн айтып ыйлап жатышты. Алардын бири жаңы эле жумушун алмаштырып, технология, адамдар жана команда менен болгон көйгөйлөрү жөнүндө айтып жатты. Канчалык көп уккан сайын ал мени жөн эле жумушка алышы керек экенин түшүндүм, анткени мен акыркы 15 жылдан бери чечип келе жаткан көйгөйлөрдүн түрлөрү. Мен айттым, эртеси жумушта таанышып калдык. Компания окутуу стратегиялары деп аталды.

Окутуу стратегиялары төрөлгөндөн үч жашка чейинки өтө кичинекей балдар үчүн окуу планынын лидери болуп саналат. Салттуу “кагаз” компаниясына 40 жыл, ал эми платформанын санариптик SaaS версиясына 10 жыл. Салыштырмалуу жакында эле санариптик технологияны компаниянын стандарттарына ыңгайлаштыруу процесси башталды. "Жаңы" версия 2017-жылы ишке киргизилген жана дээрлик эски версиясындай эле, болгону начарыраак иштеген.

Эң кызыгы, бул компаниянын трафиги абдан болжолдуу - күндөн-күнгө, жылдан жылга, сиз канча адам жана качан келерин так айта аласыз. Мисалы, саат 13:15дөн XNUMX:XNUMXгө чейин бала бакчадагы бардык балдар уктап, мугалимдер маалымат киргизе башташат. Ал эми дем алыш күндөрүн кошпогондо, бул күн сайын болот, анткени дем алыш күндөрү дээрлик эч ким иштебейт.

Бир аз алдыга карап, мен өз ишимди ар кандай себептерден улам кызыктуу болгон эң көп жылдык трафиктин мезгилинде баштаганымды белгилейм.

Болгону 2 жылдай көрүнгөн платформа өзгөчө стекке ээ болгон: 2008-жылдан бери ColdFusion & SQL Server. ColdFusion, эгер сиз билбесеңиз жана балким билбесеңиз, бул 90-жылдардын ортосунда чыккан ишкана PHP, ошондон бери мен ал жөнүндө уккан да эмесмин. Ошондой эле бар болчу: Ruby, MySQL, PostgreSQL, Java, Go, Python. Бирок негизги монолит ColdFusion жана SQL Server боюнча чуркап.

көйгөйлөр

Ишкананын кызматкерлери менен иш жана кандай көйгөйлөргө дуушар болгондугу тууралуу көбүрөөк сүйлөшкөн сайын, көйгөйлөр техникалык мүнөздө гана эмес экенин түшүндүм. Макул, технология эски - жана алар мунун үстүндө иштеген жок, бирок командада жана процесстерде көйгөйлөр бар жана компания муну түшүнө баштады.

Адаттагыдай эле, алардын техникалык кызматкерлери бурчта отуруп, кандайдыр бир иштерди жасашчу. Бирок барган сайын көбүрөөк бизнес санариптик версия аркылуу өтө баштады. Ошондуктан, мен иштей баштаганга чейин акыркы жылы компанияда жаңылары пайда болду: директорлор кеңеши, CTO, CPO жана QA директору. Башкача айтканда, компания технология тармагына инвестициялай баштады.

Оор мурастын издери системаларда гана болгон эмес. Компаниянын мурас процесстери, мурас адамдары, мурас маданияты болгон. Мунун баарын өзгөртүү керек болчу. Мен бул, албетте, зериктирбейт деп ойлогом жана аны сынап көрүүнү чечтим.

Эки күн мурун

Жаңы жумушка киришерден эки күн мурун кеңсеге келип, акыркы документтерди толтурдум, команда менен жолугуп, команда ошол учурда көйгөй менен күрөшүп жатканын билдим. Бул орточо баракты жүктөө убактысы 4 секундага, башкача айтканда, 2 эсеге секирип кеткен.

Графикке караганда, бир нерсе болду жана эмне болгону белгисиз. Көйгөй маалымат борборундагы тармактын кечигүүсүндө экени белгилүү болду: маалымат борборундагы 5 мс кечигүү колдонуучулар үчүн 2 секундага айланды. Мен эмне үчүн мындай болгонун билген жокмун, бирок кандай болгон күндө да маселе маалымат борборунда экени белгилүү болду.

күнү бир

Арадан эки күн өтүп, биринчи жумуш күнүмдө эле көйгөй чечилбегенин билдим.

Эки күн ичинде колдонуучулардын баракчалары орто эсеп менен 4 секундада жүктөлгөн. Мен алар көйгөй эмнеде экенин табыштыбы деп сурайм.

- Ооба, билет ачтык.
- ЖАНА?
- Ооба, алар бизге жооп бере элек.

Ошондо мен буга чейин айтылгандардын баары мен күрөшүшүм керек болгон айсбергдин кичинекей бир чети экенин түшүндүм.

Буга абдан туура келген жакшы цитата бар:

"Кээде технологияны өзгөртүү үчүн уюмду өзгөртүүгө туура келет."

Бирок мен жумушту жылдын эң кызуу убагында баштагандыктан, маселени чечүүнүн эки вариантын тең карап чыгууга туура келди: тез жана узак мөөнөттүү. Жана азыр эң маанилүү нерседен баштаңыз.

күн, үч

Ошентип, жүктөө 4 секундга созулат, ал эми 13төн 15ке чейин эң чоң чокулар.

Бул убакыттын ичинде үчүнчү күнү, жүктөө ылдамдыгы төмөнкүдөй болду:

Менин көз карашым боюнча, эч нерсе иштебеди. Башкалардын көз карашы боюнча, ал демейдегиден бир аз жайыраак иштеп жаткан. Бирок мындай болбойт — бул олуттуу маселе.

Мен команданы ишендирүүгө аракет кылдым, алар аларга көбүрөөк серверлер керек деп жооп беришти. Бул, албетте, көйгөйдү чечүү болуп саналат, бирок ал дайыма эле жалгыз жана эң натыйжалуу боло бербейт. Эмне үчүн серверлер жетишсиз, трафиктин көлөмү кандай деп сурадым. Мен маалыматтарды экстраполяцияладым жана бизде секундасына болжол менен 150 сурам бар экенин таптым, бул негизинен акылга сыярлык чектерге туура келет.

Бирок туура жооп алуудан мурун туура суроо берүү керектигин унутпашыбыз керек. Менин кийинки суроом мындай болду: бизде канча сервер бар? Жооп "мени бир аз таң калтырды" - бизде 17 сервер бар болчу!

— Сурагандан уялып жатам, бирок 150 17ге бөлгөндө 8ге жакын болот? Ар бир сервер секундасына 8 суроого уруксат берет деп жатасызбы, эртең секундасына 160 суроо-талап болсо, бизге дагы 2 сервер керек болот?

Албетте, бизге кошумча серверлердин кереги жок болчу. Чечим коддун өзүндө жана бетинде болгон:

var currentClass = classes.getCurrentClass();
return currentClass;

Функция бар болчу getCurrentClass(), анткени сайтта бардыгы класстын контекстинде иштейт - бул туура. Бул үчүн ар бир баракта бир функция бар болчу 200+ өтүнүч.

Бул жол менен чечүү абдан жөнөкөй эле, ал тургай, эч нерсе кайра жазууга туура келген эмес: жөн гана кайра ошол эле маалыматты сураба.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Мен абдан сүйүндүм, анткени үчүнчү күнү эле негизги көйгөйдү таптым деп чечтим. Мен канчалык жөнөкөй болсом да, бул көп көйгөйлөрдүн бири эле.

Бирок бул биринчи маселени чечүү графикти бир топ төмөн түшүрдү.

Ошол эле учурда биз башка оптималдаштырууларды жасап жатканбыз. Оңдосо боло турган көп нерселер көрүндү. Мисалы, ошол эле үчүнчү күнү мен системада кэш бар экенин билдим (башында мен бардык сурамдар түз маалымат базасынан келип жатат деп ойлогом). Мен кэш жөнүндө ойлонгондо, мен стандарттуу Redis же Memcached жөнүндө ойлоном. Бирок мен жалгыз ушундай деп ойлогом, анткени бул система кэштөө үчүн MongoDB жана SQL Server колдонгон - ошол эле маалыматтар жаңы эле окулган.

Он күн

Биринчи жумада мен азыр чечилиши керек болгон көйгөйлөр менен алектендим. Экинчи жумада кайсы бир жерде команда менен баарлашуу, эмне болуп жатканын жана бүт процесс кандай жүрүп жатканын көрүү үчүн биринчи жолу стендге келдим.

Дагы бир кызыктуу нерсе табылды. Команданын курамында: 18 иштеп чыгуучулар; 8 сыноочу; 3 менеджер; 2 архитектор. Жана алардын бардыгы жалпы ырым-жырымдарга катышышты, башкача айтканда, 30дан ашык адам күн сайын эртең менен стендге келип, эмне кылганын айтып беришти. Жыйын 5 же 15 мүнөткө созулбаганы көрүнүп турат. Эч ким эч кимди укпады, анткени ар ким ар кандай системада иштейт. Бул формада бир саатына 2-3 билет жакшы натыйжа болгон.

Биз кылган биринчи нерсе команданы бир нече продукт линияларына бөлдүк. Ар кандай бөлүмдөр жана системалар үчүн биз иштеп чыгуучуларды, сыноочуларды, продукт менеджерлерин жана бизнес-аналитиктерди камтыган өзүнчө командаларды бөлдүк.

Натыйжада биз алдык:

• Митингдерди жана митингдерди кыскартуу.
• Продукциянын предметтик билими.
• Менчик сезими. Адамдар ар дайым системалар менен алектенип жүргөндө, алар башка бирөөнүн мүчүлүштүктөрү менен иштеши мүмкүн экенин билишкен, бирок өздөрү эмес.
• Топтор ортосундагы кызматташтык. Айта кетчү нерсе, QA мурун программисттер менен көп сүйлөшкөн эмес, продукт өз ишин жасаган ж.б. Эми аларда жалпы жоопкерчилик бар.

Биз негизинен эффективдүүлүккө, өндүрүмдүүлүккө жана сапатка басым жасадык – бул көйгөйлөрдү биз коллективди кайра өзгөртүү менен чечүүгө аракет кылдык.

Он биринчи күн

Команданын структурасын өзгөртүү процессинде мен кантип санаш керектигин таптым баянPoints. 1 SP бир күнгө барабар болгон жана ар бир билетте өнүгүү жана QA үчүн SP камтылган, башкача айтканда, жок дегенде 2 SP.

Мен муну кантип таптым?

Биз мүчүлүштүктөрдү таптык: отчеттордун биринде отчет талап кылынган мезгилдин башталышы жана аяктоо датасы жазылган, акыркы күн эсепке алынган эмес. Башкача айтканда, сурамдын бир жеринде <= эмес, жөн гана < болгон. Мага бул үч Story Points деп айтышты, башкача айтканда 3 күн.

Андан кийин биз:

• Story Points рейтинг системасы кайра каралып чыкты. Эми система аркылуу тез өтүүчү майда мүчүлүштүктөр үчүн оңдоолор колдонуучуга тезирээк жетет.
• Биз иштеп чыгуу жана сыноо үчүн тиешелүү билеттерди бириктире баштадык. Буга чейин ар бир билет, ар бир мүчүлүштүк эч нерсеге байланбаган жабык экосистема болчу. Бир беттеги үч баскычты өзгөртүү ар бир бетке бир автоматташтырылган тесттин ордуна үч түрдүү QA процесси менен үч башка билет болушу мүмкүн.
• Биз иштеп чыгуучулар менен эмгек чыгымдарын баалоо ыкмасы боюнча иштей баштадык. Бир баскычты өзгөртүү үчүн үч күн күлкүлүү эмес.

Жыйырманчы күн

Биринчи айдын ортосунда бир жерде кырдаал бир аз турукташып калды, мен негизинен эмне болуп жатканын түшүндүм жана келечекти карап, узак мөөнөттүү чечимдер жөнүндө ойлоно баштадым.

Узак мөөнөттүү максаттар:

• Башкарылган платформа. Ар бир беттеги жүздөгөн өтүнүчтөр олуттуу эмес.
• Болжолдуу тенденциялар. Бир караганда башка көрсөткүчтөр менен дал келбеген мезгил-мезгили менен трафиктин чокулары болгон - биз эмне үчүн мындай болгонун түшүнүп, алдын ала айтууну үйрөнүшүбүз керек болчу.
• Платформаны кеңейтүү. Бизнес тынымсыз өсүп жатат, көбүрөөк колдонуучулар келип, трафик көбөйүүдө.

Илгери көп айтылат: "Келгиле, баарын [тилде/алкакта] кайра жазалы, баары жакшыраак иштейт!"

Көпчүлүк учурларда бул иштебейт, эгер кайра жазуу такыр иштесе жакшы болот. Ошондуктан, биз жол картасын түзүшүбүз керек болчу - бизнес максаттарына кантип жетээрин (эмне жана эмне үчүн) этап-этабы менен чагылдырган конкреттүү стратегия:

• долбоордун миссиясын жана максаттарын чагылдырат;
• негизги максаттарга артыкчылык берет;
• аларга жетүү үчүн графикти камтыйт.

Буга чейин эч ким команда менен кандайдыр бир өзгөрүүлөрдүн максаты жөнүндө сүйлөшкөн эмес. Бул туура ийгилик көрсөткүчтөрүн талап кылат. Компаниянын тарыхында биринчи жолу биз техникалык топко KPI койдук жана бул көрсөткүчтөр уюштуруучулук көрсөткүчтөр менен байланыштырылды.

Башкача айтканда, уюштуруучулук KPI командалар тарабынан колдоого алынат, ал эми командалык KPI жеке KPIлер тарабынан колдоого алынат. Болбосо, технологиялык KPI уюштуруучулук менен дал келбесе, анда ар бир адам жуурканды өзүнө тартат.

Мисалы, уюштуруучулук KPIлердин бири жаңы өнүмдөр аркылуу рыноктун үлүшүн көбөйтүү.

Көбүрөөк жаңы өнүмгө ээ болуу максатын кантип колдой аласыз?

• Биринчиден, биз кемчиликтерди оңдоонун ордуна жаңы өнүмдөрдү иштеп чыгууга көбүрөөк убакыт короткубуз келет. Бул өлчөө үчүн оңой болгон логикалык чечим.
• Экинчиден, биз транзакциянын көлөмүн көбөйтүүнү колдогубуз келет, анткени рыноктун үлүшү канчалык көп болсо, ошончолук көп колдонуучулар жана ошончолук көп трафик.

Ошондо топтун ичинде аткарыла турган жеке KPI, мисалы, негизги кемчиликтер келип чыккан жерде болот. Эгер сиз бул бөлүмгө өзгөчө көңүл бурсаңыз, анда кемчиликтер бир топ азыраак экенине ынансаңыз болот, андан кийин жаңы өнүмдөрдү иштеп чыгуу жана кайра уюштуруунун KPIлерин колдоо үчүн убакыт көбөйөт.

Ошентип, ар бир чечим, анын ичинде кайра жазуу коду, компания бизге койгон конкреттүү максаттарды (уюштуруучулук өсүш, жаңы функциялар, жалдоо) колдоого алышы керек.

Бул процесстин жүрүшүндө кызыктуу нерсе ачыкка чыкты, ал техникалык адистер үчүн гана эмес, жалпысынан компания үчүн жаңылык болуп калды: бардык билеттер жок дегенде бир KPIге багытталышы керек. Башкача айтканда, эгерде продукт жаңы функцияны жасагысы келсе, биринчи суроо берилиши керек: "Бул функция кандай KPI колдойт?" Эгерде жок болсо, анда кечиресиз - бул керексиз өзгөчөлүк окшойт.

Отуз күн

Айдын аягында мен дагы бир нюанс таптым: менин Ops командамдагы эч ким биздин кардарлар менен түзгөн келишимдерди көргөн эмес. Сиз эмне үчүн байланыштарды көрүшүңүз керектигин сурасаңыз болот.

• Биринчиден, анткени SLAлар келишимдерде көрсөтүлгөн.
• Экинчиден, SLA баары ар кандай. Ар бир кардар өзүнүн талаптары менен келип, сатуу бөлүмү карабай туруп кол койду.

Дагы бир кызыктуу нюанс - ири кардарлардын бири менен түзүлгөн келишимде платформа тарабынан колдоого алынган бардык программалык камсыздоо версиялары n-1 болушу керек, башкача айтканда, акыркы версия эмес, акыркы версиясы болушу керек.

Платформа ColdFusion жана SQL Server 1ге негизделсе, июлда таптакыр колдоого алынбай калган болсо, биз n-2008ден канчалык алыс экенибиз түшүнүктүү.

Кырк бешинчи күн

Экинчи айдын ортосуна жакын отуруп, иштөөгө жетиштүү убакыт болду Наркыагымкартасын түзүү бүт процесс үчүн толугу менен. Булар бир продуктту түзүүдөн баштап, аны керектөөчүгө жеткирүүгө чейин жасалышы керек болгон зарыл кадамдар жана алар мүмкүн болушунча кеңири сүрөттөлүшү керек.

Сиз процессти майда бөлүктөргө бөлүп, эмнеге көп убакыт талап кылынарын, эмнени оптималдаштырууга, жакшыртууга ж.б. Мисалы, өнүм сурамынын кароодон өтүшүнө канча убакыт кетет, ал иштеп чыгуучу ала турган билетке качан жетет, QA ж.б. Ошентип, сиз ар бир кадамды майда-чүйдөсүнө чейин карап, эмнени оптималдаштырса болот деп ойлонуңуз.

Муну кылганда, эки нерсе көзүмө урунду:

• QAдан кайра иштеп чыгуучуларга кайтарылган билеттердин жогорку пайызы;
• тартуу өтүнүчүн карап чыгуу өтө көпкө созулду.

Маселе мына ушунда болгон: Бул көп убакытты талап кылат окшойт, бирок канча убакытка созуларын билбейбиз.

"Өлчөө албаган нерсени жакшырта албайсың."

Проблеманын канчалык олуттуу экендигин кантип актоого болот? Күндөрдү же сааттарды текке кетиреби?

Муну өлчөө үчүн, биз Jira процессине бир нече кадамдарды коштук: ар бир билет канча убакыт күтөрүн жана ал белгилүү бир кадамга канча жолу кайтып келерин өлчөө үчүн “дештирүү үчүн даяр” жана “QA үчүн даяр”.

Карап чыгуу үчүн орто эсеп менен канча билет бар экенин билүү үчүн "карап чыгууда" дегенди да коштук, ошондон баштап бийлей баштасаңыз болот. Бизде системалык көрсөткүчтөр бар болчу, эми биз жаңы көрсөткүчтөрдү кошуп, өлчөй баштадык:

• Процесстин эффективдүүлүгү: аткаруу жана пландаштырылган/жеткизилген.
• Процесс сапаты: дефекттердин саны, сапаты боюнча кемчиликтер.

Бул чындап эле эмне жакшы, эмне жакшы эмес экенин түшүнүүгө жардам берет.

Элүүнчү күн

Мунун баары, албетте, жакшы жана кызыктуу, бирок экинчи айдын аягында мен мындай масштабды күткөн эмесмин, бирок, негизинен, алдын ала бир нерсе болду. Жогорку жетекчилик алмашкандыктан эл кете баштады. Жетекчиликке жаңы адамдар келип, баарын өзгөртө башташты, эскилери иштен кетишти. Ал эми, адатта, бир нече жыл болгон компанияда, баары дос жана баары бири-бирин тааныйт.

Бул күтүлгөн эле, бирок кыскартуулардын масштабы күтүүсүз болду. Мисалы, бир жуманын ичинде бир эле учурда эки команда лидери өз каалоосу менен отставкага кетүү боюнча арыз жазышкан. Ошондуктан, мен башка көйгөйлөрдү унутуп эле койбостон, көңүл бурууга туура келди команда түзүү. Бул узак жана татаал маселе, бирок аны чечүү керек болчу, анткени мен калган адамдарды (же алардын көпчүлүгүн) сактап калгым келген. Командада моралдык маанайды сактап калуу үчүн адамдардын кетип калганына кандайдыр бир реакция жасоо керек болчу.

Теориялык жактан алганда, бул жакшы: жаңы адам келет, анын карт-бланшы толук бар, ал команданын жөндөмүн баалай алат жана персоналды алмаштыра алат. Чынында, сиз жөн гана көптөгөн себептерден улам жаңы адамдарды алып келе албайсыз. Баланс ар дайым керек.

• Эски жана жаңы. Биз миссияны өзгөртө ала турган жана колдой турган карыларды калтырышыбыз керек. Бирок, ошол эле учурда, биз жаңы кан алып келиши керек, биз бир аз кийинчерээк бул тууралуу сүйлөшөбүз.
• Тажрыйба. Биз менен иштешүүнү каалаган, дилгир жаштар менен көп сүйлөштүм. Бирок мен аларды кабыл ала алган жокмун, анткени кенжелерге колдоо көрсөтүп, аларга насаатчы боло турган улуулар жетишсиз. Алгач жогоркуларды, андан кийин гана жаштарды алуу керек эле.
• Сабиз жана таяк.

Туура тең салмактуулук деген эмне, аны кантип сактоо керек, канча адамды кармаш керек, канча түртүш керек деген суроолорго так жооп бере албайм. Бул жекече процесс.

Элүү биринчи күн

Мен ким экенимди түшүнүү үчүн команданы жакшылап карай баштадым жана дагы бир жолу эстедим:

"Көйгөйлөрдүн көбү адамдардын көйгөйлөрү."

Мен команданын - Dev жана Ops экөөнүн тең үч чоң көйгөйү бар экенин көрдүм:

• Иштин азыркы абалына канааттануу.
• Жоопкерчиликтин жоктугу - анткени эч ким бизнеске таасир этүү үчүн аткаруучулардын ишинин жыйынтыгын алып келе элек.
• Өзгөрүүдөн коркуу.

Өзгөрүүлөр ар дайым сизди өзүңүздүн ыңгайлуу зонаңыздан алып чыгат жана жаштар канчалык жаш болсо, алар өзгөрүүнү ошончолук жактырбайт, анткени алар эмне үчүн жана кантип түшүнүшпөйт. Мен уккан эң көп жооп: "Биз эч качан мындай кылган эмеспиз". Анын үстүнө, ал толугу менен абсурддук чекке жетти - кичинекей өзгөрүүлөр кимдир бирөөнүн кыжырданбай туруп болушу мүмкүн эмес. Ал эми өзгөрүүлөр алардын ишине канчалык таасир этсе да, эл: «Жок, эмнеге? Бул иштебейт."

Бирок эч нерсени өзгөртпөстөн жакшы боло албайсың.

Мен бир кызматкер менен абсурддуу сүйлөштүм, мен ага оптималдаштыруу боюнча идеяларымды айттым, ал мага мындай деди:
- Ой, былтыр бизде эмне болгонун көргөн жоксуң!
- Анан эмне?
"Азыр мурункуга караганда алда канча жакшы."
- Демек, мындан жакшыраак болушу мүмкүн эмес?
- Эмне үчүн?

Жакшы суроо - эмне үчүн? Мурункуга караганда азыр жакшы болсо, баары жакшы дегендей. Бул жоопкерчиликтин жоктугуна алып келет, бул принципиалдуу түрдө нормалдуу көрүнүш. Айткандай эле техникалык топ бир аз четте калыптыр. Компания алар болушу керек деп эсептеген, бирок эч ким эч качан стандарттарды койгон эмес. Техникалык колдоо эч качан SLAны көргөн эмес, андыктан бул топ үчүн "кабыл алынарлык" болгон (жана бул мага эң катуу тийген):

• 12 секунд жүктөө;
• Ар бир чыгарылыш 5-10 мүнөт токтоп калуу;
• Кыйынчылыктарды жоюу күндөрдү жана жумаларды талап кылат;
• 24x7 / нөөмөт боюнча персоналдын жетишсиздиги.

Эч ким эмне үчүн биз муну жакшыраак кылбайбыз деп суроого аракет кылган эмес жана эч ким мындай болушу керек эмес экенин түшүнгөн эмес.

Бонус катары дагы бир көйгөй бар эле: тажрыйбанын жоктугу. Чоңдор кетип, калган жаш команда мурунку режимдин тушунда чоңоюп, ага ууланган.

Анын үстүнө, адамдар да ийгиликсиз болуп, жөндөмсүз болуп көрүнүүдөн коркушчу. Бул, биринчиден, алар эч кандай шартта жардам сураган эмес. Канча жолу топ болуп, жекече сүйлөштүк, мен: “Бир нерсе кылганды билбесеңер, суроо бергиле” дедим. Мен өзүмө ишенем жана каалаган маселени чече аларымды билем, бирок бул убакытты талап кылат. Ошондуктан, 10 мүнөттө кантип чечүүнү билген бирөөдөн сурасам, сурайм. Канчалык аз тажрыйбаңыз болсо, ошончолук суроо берүүдөн коркосуз, анткени сиз өзүңүздү жөндөмсүз деп эсептейсиз.

Суроо берүүдөн коркуу кызыктуу жолдор менен көрүнөт. Мисалы, сиз: "Бул тапшырманы кандай аткарып жатасыз?" - "Бир-эки саат калды, мен бүтүп жатам." Эртеси кайра сурайсың, баары жакшы, бирок бир көйгөй бар эле, күндүн акырына чейин сөзсүз даяр болот деген жооп аласың. Дагы бир күн өтөт, сиз дубалга кадап, бирөө менен сүйлөшүүгө мажбур болгуча, бул улана берет. Адам бир көйгөйдү өзү чечүүнү каалайт, эгер аны өзү чечпесе, бул чоң ийгиликсиздик болот деп ишенет.

Мына ушул себептен иштеп чыгуучулар сметаларды жогорулатып. Ошол эле анекдот болчу, алар кандайдыр бир тапшырманы талкуулашканда, мага ушундай цифра беришкен, мен абдан таң калдым. Мага иштеп чыгуучунун баалоосунда иштеп чыгуучу билеттин QAдан кайтарылып бериле турган убактысын камтыйт деп айтышты, анткени алар ал жерден каталарды табат, пиарга кетчү убакыт жана карап чыгууга тийиш болгон адамдар. ал бош эмес болот - башкача айтканда, бардыгы , мүмкүн болгон нерсе.

Экинчиден, жөндөмсүз болуп көрүнүүдөн корккон адамдар ашыкча талдоо. Эмне кылуу керек экенин айтканда, ал: "Жок, бул жерде ойлонуп көрсөк эмне болот?" Бул жагынан алганда, биздин компания уникалдуу эмес, бул жаштар үчүн стандарттуу көйгөй.

Жооп катары мен төмөнкү практикаларды киргиздим:

• Эреже 30 мүнөт. Жарым саатта маселени чече албасаңыз, бирөөдөн жардам сураңыз. Бул ийгиликтин ар кандай даражалары менен иштейт, анткени адамдар дагы деле сурашпайт, бирок, жок дегенде, процесс башталды.
• Маңыздан башканын баарын жок кыл, тапшырманы аткаруунун акыркы мөөнөтүн эсептөөдө, башкача айтканда, кодду жазууга канча убакыт керектелерин гана эсептеңиз.
• Өмүр бою билим алуу ашыкча талдоо кылгандар үчүн. Бул жөн гана адамдар менен туруктуу иштөө.

Алтымышынчы күн

Мен мунун баарын жасап жатып, бюджетти аныктоого убакыт келди. Албетте, акчабызды кайда жумшаганыбыздан көп кызыктуу нерселерди таптым. Мисалы, бизде бир кардар колдонгон бир FTP сервери бар өзүнчө маалымат борборунда бүтүндөй стойка бар болчу. Көрсө, “... көчүп кеттик, бирок ал ушинтип калды, биз аны өзгөрткөн жокпуз” деп чыкты. 2 жыл мурун болгон.

Булут кызматтары үчүн мыйзам долбоору өзгөчө кызыгууну жаратты. Менин оюмча, булуттун жогору болушунун негизги себеби - бул жашоодо биринчи жолу серверлерге чексиз кирүү мүмкүнчүлүгү бар иштеп чыгуучулар. Аларга: "Мага тесттик сервер бериңизчи" деп суроонун кереги жок, алар өздөрү кабыл алышат. Мындан тышкары, иштеп чыгуучулар дайыма Facebook жана Netflix көрө албастык кыла турган сонун системаны кургусу келет.

Бирок иштеп чыгуучулардын серверлерди сатып алуу тажрыйбасы жана серверлердин талап кылынган өлчөмүн аныктоо чеберчилиги жок, анткени аларга буга чейин кереги жок болчу. Жана алар, адатта, масштабдуулук менен аткаруунун ортосундагы айырманы түшүнүшпөйт.

Инвентаризация жыйынтыгы:

• Биз ошол эле маалымат борборунан чыктык.
• Биз 3 журнал кызматы менен келишимди токтоттук. Анткени бизде алардын 5и бар болчу - бир нерсе менен ойной баштаган ар бир иштеп чыгуучу жаңысын алды.
• 7 AWS системасы өчүрүлгөн. Кайрадан өлүп калган долбоорлорду эч ким токтоткон жок, бардыгы иштей беришти.
• Программалык камсыздоонун баасы 6 эсеге кыскарды.

Жетимиш бешинчи күн

Убакыт өтүп, эки жарым айдан кийин директорлор кеңеши менен жолугушууга туура келди. Биздин директорлор кеңеши башкалардан жакшы же жаман эмес; бардык директорлор кеңештери сыяктуу эле ал баарын билгиси келет. Адамдар акча салышат жана биздин ишибиз белгиленген KPIлерге канчалык туура келерин түшүнгүсү келет.

Директорлор кеңеши ай сайын көптөгөн маалыматтарды алат: колдонуучулардын саны, алардын өсүшү, алар кандай кызматтарды жана кантип колдонушу, өндүрүмдүүлүгү жана өндүрүмдүүлүгү, акырында, баракчаны жүктөө ылдамдыгы.

Бир гана маселе, мен орточо таза жамандык деп эсептейм. Бирок муну директорлор кеңешине түшүндүрүү өтө кыйын. Алар, мисалы, секундасына жүктөө убактысынын жайылышы эмес, жалпыланган сандар менен иштөөгө көнүшкөн.

Буга байланыштуу кызыктуу жагдайлар болду. Мисалы, мен трафикти мазмундун түрүнө жараша өзүнчө веб-серверлердин ортосунда бөлүштүрүү керек деп айттым.

Башкача айтканда, ColdFusion Jetty жана nginx аркылуу өтүп, баракчаларды ишке киргизет. Жана сүрөттөр, JS жана CSS өз конфигурациялары менен өзүнчө nginx аркылуу өтөт. Бул мен айтып жаткан кыйла стандарттуу практика Мен мындай деп жазган бир нече жыл мурун. Натыйжада, сүрөттөр бир топ тез жүктөлөт жана... жүктөөнүн орточо ылдамдыгы 200 мс көбөйдү.

Бул график Jetty менен келген маалыматтардын негизинде курулгандыктан болду. Башкача айтканда, тез мазмун эсептөөгө киргизилген эмес - орточо мааниси секирип кетти. Бул бизге түшүнүктүү болду, күлдүк, бирок директорлор кеңешине эмне үчүн бир нерсе кылып, 12% начарлап кеткенибизди кантип түшүндүрөбүз?

Сексен бешинчи күн

Үчүнчү айдын аягында мен такыр эсептелбеген бир нерсе бар экенин түшүндүм: убакыт. Мен айткандардын баары убакытты талап кылат.

Бул менин чыныгы жумалык календарым - жөн гана жумуш жумасы, өтө бош эмес. Баарына убакыт жетпейт. Ошондуктан, дагы бир жолу, сиз көйгөйлөр менен күрөшүүгө жардам бере турган адамдарды жалдоо керек.

жыйынтыктоо

Бул баары эмес. Бул окуяда мен өнүм менен кантип иштешкенибизди жана жалпы толкунга көнүүгө аракет кылганыбызды, же техникалык колдоону кантип бириктиргенибизди же башка техникалык көйгөйлөрдү кантип чечкенибизди түшүнө элекмин. Мисалы, мен кокусунан билдим, базанын эң чоң таблицаларында биз колдонбойбуз SEQUENCE. Бизде өз алдынча жазылган функция бар nextID, жана ал транзакцияда колдонулбайт.

Биз көпкө чейин сүйлөшө турган миллиондогон окшош нерселер бар болчу. Бирок дагы айта кете турган эң негизги нерсе – маданият.

Маданият же анын жоктугу бардык башка көйгөйлөргө алып келет. Биз маданиятты курууга аракет кылып жатабыз, анда адамдар:

• ийгиликсиздиктерден коркпогула;
• каталардан сабак алуу;
• башка командалар менен кызматташуу;
• демилгени колго алуу;
• жоопкерчилик алуу;
• натыйжаны максат катары кабыл алуу;
• ийгиликти майрамдоо.

Муну менен башканын баары келет.

Leon Fire Твиттерде, Facebook жана орто.

Мураска байланыштуу эки стратегия бар: кандай болсо да аны менен иштөөдөн качуу же ага байланышкан кыйынчылыктарды кайраттуулук менен жеңүү. Биз в DevOpsConf Биз экинчи жолго түшүп, процесстерди жана мамилени өзгөртүп жатабыз. Бизге кошулуңуз YouTube, почта тизмеси и телеграмма, жана биз бирге DevOps маданиятын ишке ашырабыз.

Source: www.habr.com