Дали е тешко да се сфати главната поента кога се зборува за DevOps? Собравме за вас живописни аналогии, впечатливи формулации и совети од експерти кои ќе им помогнат дури и на неспецијалистите да дојдат до поентата. На крајот, бонусот е DevOps на вработените во Red Hat.
Терминот DevOps настана пред 10 години и од хаштаг на Твитер стана моќно културно движење во ИТ светот, вистинска филозофија која ги охрабрува програмерите да ги завршат работите побрзо, да експериментираат и да повторуваат напред. DevOps стана нераскинливо поврзан со концептот на дигитална трансформација. Но, како што често се случува со ИТ терминологијата, во текот на изминатите десет години DevOps доби многу дефиниции, толкувања и заблуди за себе.
Затоа, често може да слушнете прашања за DevOps како, дали е исто што и агилно? Или ова е некоја посебна методологија? Или тоа е само уште еден синоним за зборот „соработка“?
DevOps вклучува многу различни концепти (континуирана испорака, континуирана интеграција, автоматизација, итн.), така што дестилирањето на она што е важно може да биде предизвик, особено кога сте страсни за темата. Сепак, оваа вештина е многу корисна, без разлика дали се обидувате да ги пренесете своите идеи до претпоставените или едноставно да му кажувате на некој од вашето семејство или пријатели за вашата работа. Затоа, засега да ги оставиме настрана терминолошките нијанси на DevOps и да се фокусираме на големата слика.
Што е DevOps: 6 дефиниции и аналогии
Побаравме експерти да ја објаснат суштината на DevOps што е можно поедноставно и накратко, така што неговата вредност ќе им стане јасна на читателите со кое било ниво на техничко знаење. Врз основа на резултатите од овие разговори, ги избравме највпечатливите аналогии и впечатливи формулации кои ќе ви помогнат да ја изградите вашата приказна за DevOps.
1. DevOps е културно движење
„DevOps е културно движење во кое двете страни (развивачи на софтвер и специјалисти за работа на ИТ системи) препознаваат дека софтверот не носи вистинска корист додека некој не почне да го користи: клиенти, клиенти, вработени, а не поентата“, вели Евелин Оерлих, постар истражувач. аналитичар во Институтот DevOps. „Затоа, двете страни заеднички обезбедуваат брза и висококвалитетна испорака на софтвер“.
2. DevOps е за зајакнување на програмерите.
„DevOps им овозможува на програмерите да поседуваат апликации, да ги извршуваат и да управуваат со испораката од почеток до крај“.
„Вообичаено, DevOps се зборува како начин да се забрза испораката на апликации до производство преку градење и имплементирање на автоматизирани процеси“, вели Џаи Шнип, директор на платформите DevOps во осигурителната компанија Liberty Mutual. „Но, за мене тоа е многу пофундаментална работа“. DevOps им дава овластување на програмерите да поседуваат апликации или одредени делови од софтвер, да ги извршуваат и да управуваат со нивната испорака од почеток до крај. DevOps ја елиминира конфузијата во одговорноста и ги води сите вклучени во создавање автоматизирана инфраструктура управувана од развивачите.
3. DevOps е за соработка при креирање и доставување апликации.
„Едноставно кажано, DevOps е пристап кон производство и испорака на софтвер каде што сите работат заедно“, вели Гур Стаф, претседател и шеф на дигитална бизнис автоматизација во BMC.
4. DevOps е цевковод
„Склопувањето на транспортер е можно само ако сите делови се вклопуваат заедно“.
„Би го споредил DevOps со линија за склопување автомобили“, продолжува Gur Staff. – Идејата е однапред да се дизајнираат и изработат сите делови за потоа да се склопат без индивидуално прилагодување. Склопувањето на транспортерот е можно само ако сите делови се вклопуваат заедно. Оние кои дизајнираат и градат мотор мора да размислат како да го монтираат на каросеријата или рамката. Тие што ги прават сопирачките мора да размислуваат за тркалата итн. Истото треба да биде и со софтверот.
Програмер кој создава деловна логика или кориснички интерфејс мора да размисли за базата на податоци што ги складира информациите за клиентите, безбедносните мерки за заштита на податоците на корисниците и како сето ова ќе функционира кога услугата ќе почне да опслужува голема, можеби дури и повеќемилионска корисничка публика .
„Да ги натерате луѓето да соработуваат и да размислуваат за деловите од работата што другите ги работат, наместо да се фокусираат само на сопствените задачи, е најголемата пречка што треба да се надмине. Ако можете да го направите ова, имате одлични шанси за дигитална трансформација“, додава Gur Staff.
5. DevOps е вистинската комбинација на луѓе, процеси и автоматизација
Џејн Грол, извршен директор на Институтот DevOps, понуди одлична аналогија за објаснување на DevOps. Според нејзините зборови, „DevOps е како рецепт со три главни категории состојки: луѓе, процес и автоматизација. Повеќето од овие состојки може да се земат од други области и извори: Lean, Agile, SRE, CI/CD, ITIL, лидерство, култура, алатки. Тајната на DevOps, како и секој добар рецепт, е како да ги добиете вистинските пропорции и мешање на овие состојки за да ја зголемите брзината и ефикасноста на креирањето и објавувањето апликации.
6. DevOps е кога програмерите работат како тим од Формула 1
„Трката не е планирана од почеток до крај, туку напротив, од цел до почеток.
„Кога зборувам за тоа што да очекувам од иницијативата на DevOps, мислам на NASCAR или Формула 1 тркачки тим како пример“, вели Крис Шорт, постар менаџер за маркетинг на облак платформа во Red Hat и издавач на билтенот DevOps'ish. – Водачот на таков тим има една цел: да го заземе највисокото можно место на крајот од трката, земајќи ги предвид ресурсите со кои располага тимот и предизвиците што го снашле. Во овој случај, трката се планира не од почеток до крај, туку напротив, од цел до почеток. Прво се поставува амбициозна цел, а потоа се одредуваат начините за нејзино постигнување. Потоа тие се поделени на подзадачи и делегирани на членовите на тимот“.
„Тимот ја поминува цела недела пред трката усовршувајќи го пит-стопот. Тој прави тренинзи за сила и кардио за да остане во форма за напорниот ден на трката. Вежбајте да работите заедно за да ги решите сите проблеми што може да се појават за време на трката. Исто така, тимот за развој треба да ја тренира вештината за често објавување на нови верзии. Доколку имате такви вештини и добро функционира безбедносен систем, лансирањето на нови верзии во производство исто така се случува почесто. Во овој светоглед, зголемената брзина значи зголемена безбедност“, вели Шорт.
„Не се работи за правење на „правилната работа“, додава Шорт, „тоа е да се елиминираат што е можно повеќе работи што стојат на патот до посакуваниот исход. Соработувајте и прилагодувајте се врз основа на повратните информации што ги добивате во реално време. Бидете подготвени за аномалии и работете на подобрување на квалитетот за да го минимизирате нивното влијание врз напредокот кон вашата цел. Ова е она што не чека во светот на DevOps“.
Како да се зголеми DevOps: 10 совети од експерти
Едноставно, DevOps и масовните DevOps се сосема различни работи. Ќе ви кажеме како да ги надминете бариерите на патот од првиот до вториот.
За многу организации, патувањето до DevOps започнува лесно и пријатно. Се создаваат мали страсни тимови, старите процеси се заменуваат со нови, а првите успеси не чекаат долго.
За жал, ова е само лажен сјај, илузија за напредок, вели Бен Гринел, управен директор и шеф на дигиталната служба во консултантската компанија Норт Хајленд. Раните победи се секако охрабрувачки, но тие не помагаат да се постигне крајната цел за широко усвојување на DevOps низ организацијата.
Лесно е да се види дека резултатот е култура на поделба меѓу „ние“ и „нив“.
„Често, организациите ги започнуваат овие пионерски проекти мислејќи дека ќе го отворат патот за мејнстрим DevOps, без да размислуваат дали другите ќе можат или ќе сакаат да го следат тој пат“, објаснува Бен Гринел. – Тимовите за имплементација на вакви проекти обично се регрутираат од самоуверени „варангијци“ кои веќе направиле нешто слично на други места, но се нови за вашата организација. Во исто време, тие се охрабруваат да ги прекршат и уништат правилата кои остануваат обврзувачки за сите други. Лесно е да се види дека резултатот е култура на „ние“ и „тие“ што го спречува трансферот на знаења и вештини“.
„И овој културен проблем е само една од причините што DevOps е тешко да се размери. Тимовите на DevOps се соочуваат со зголемени технички предизвици кои се типични за брзорастечките компании кои се први во ИТ“, рече Стив Њуман, основач и претседател на Scalyr.
„Во современиот свет, услугите се менуваат веднаш штом се појави потреба. Одлично е постојано да се имплементираат и имплементираат нови функции, но координирањето на овој процес и елиминирањето на проблемите што се појавуваат е вистинска главоболка, додава Стив Њуман. – Во многу брзорастечките организации, инженерите на тимовите со меѓуфункционални работи се борат да ја одржат видливоста на промените и каскадните ефекти на ниво на зависност што ги создава. Згора на тоа, инженерите не се среќни кога се лишени од оваа можност и, како резултат на тоа, им станува потешко да ја разберат суштината на проблемите што се појавуваат“.
Како да ги надминете овие предизвици опишани погоре и да преминете на масовно усвојување на DevOps во голема организација? Експертите повикуваат на трпение, дури и ако вашата крајна цел е да го забрзате циклусот на развој на софтвер и деловните процеси.
1. Запомнете дека за промена на културата е потребно време.
Џејн Грол, извршен директор, институт DevOps: „Според мое мислење, проширувањето на DevOps треба да биде инкрементално и итеративно како агилниот развој (и подеднакво да ја допира културата). Agile и DevOps ги нагласуваат малите тимови. Но, како што овие тимови растат по број и интеграција, завршуваме со повеќе луѓе кои прифаќаат нови начини на работа, а како резултат на тоа има масовна културна трансформација“.
2. Поминете доволно време планирајќи и избирајќи платформа
Еран Кинсбрунер, главен технички евангелист во Perfecto: „За да функционира скалирањето, тимовите на DevOps мора прво да научат да комбинираат традиционални процеси, алатки и вештини, а потоа полека да ја негуваат и стабилизираат секоја поединечна фаза на DevOps. Сè започнува со внимателно планирање на корисничките приказни и текови на вредности, проследено со пишување софтвер и контрола на верзии користејќи развој базиран на багажникот или други пристапи кои се најпогодни за разгранување и спојување на кодот.
„Потоа доаѓа фазата на интеграција и тестирање, каде што веќе е потребна скалабилна платформа за автоматизација. Ова е местото каде што е важно за тимовите на DevOps да ја изберат вистинската платформа која одговара на нивното ниво на вештини и на крајните цели на проектот.
Следната фаза е распоредување на производство и тоа треба да биде целосно автоматизирано со користење оркестрациски алатки и контејнери. Важно е да имате виртуелизирани околини во сите фази на DevOps (симулатор за производство, опкружување QA и вистинска производна средина) и секогаш да ги користите само најновите податоци за тестови за да добиете релевантни заклучоци. Аналитиката мора да биде паметна и способна да обработува големи податоци со брзи и повратни информации“.
3. Извадете ја вината од одговорност.
Гордон Хаф, евангелист на RedHat: „Создавањето систем и атмосфера што дозволува и поттикнува експериментирање овозможува она што се познати како успешни неуспеси во агилниот развој на софтвер. Ова не значи дека никој друг не е одговорен за неуспесите. Всушност, идентификувањето кој е одговорен станува уште полесно, бидејќи „да се биде одговорен“ повеќе не значи „предизвикување несреќа“. Односно, суштината на одговорноста се менува квалитативно. Четири фактори стануваат критични: степенот на нарушување, пристапи, производствени процеси и стимулации“. (Можете да прочитате повеќе за овие фактори во написот на Гордон Хаф „Лекции за DevOps: 4 аспекти на здрави експерименти“.)
4. Исчистете ја патеката напред
Бен Гринел, управен директор и раководител на дигиталната консултантска компанија Норт Хајленд: „За да се постигне размер, препорачувам да се започне програма за „расчистување на патеките“ заедно со пионерски проекти. Целта на оваа програма е да се исчисти ѓубрето што пионерите на DevOps го оставаат зад себе, како застарени правила и слични работи, така што патот напред останува јасен“.
„Дајте им на луѓето организациска поддршка и импулс преку комуникација која оди подалеку од пионерската група со широко славење на успесите на новите начини на работа. Тренирајте ги луѓето кои се вклучени во следниот бран на проекти DevOps и се нервозни поради користењето DevOps за прв пат. И запомнете дека овие луѓе се многу различни од пионерите“.
5. Демократизирајте ги алатките
Стив Њуман, основач и претседател на Scalyr: „Алатките не треба да се кријат од луѓето и треба да бидат релативно лесни за учење за секој што сака да одвои време. Ако можноста за пребарување на дневници е ограничена на три лица „потврдени“ да користат алатка, секогаш ќе имате на располагање максимум три лица за справување со проблемот, дури и ако имате многу голема компјутерска средина. Со други зборови, тука има тесно грло што може да доведе до сериозни (деловни) последици“.
6. Создадете идеални услови за тимска работа
Том Кларк, шеф на Заедничката платформа на ITV: „Можете да направите сè, но не сè одеднаш. Затоа, поставете големи цели, започнете со мали и напредувајте со брзи повторувања. Со текот на времето, ќе развиете репутација за завршување на работите, па и другите ќе сакаат да ги користат вашите методи. И не грижете се за градење на високо ефективен тим. Наместо тоа, обезбедете им на луѓето идеални услови за работа и ќе следи ефикасност“.
7. Не заборавајте за законите на Конвеј и таблите Канбан
Логан Даигл, директор за испорака на софтвер и стратегија за DevOps во CollabNetVersionOne: „Важно е да се разберат последиците од Законот на Конвеј. Во мојата лабава парафраза, овој закон вели дека производите што ги создаваме и процесите што ги користиме за да го сториме тоа, вклучително и DevOps, испаднаа да се структурирани на ист начин како и нашата организација“.
„Ако има многу силоси во една организација, а контролата се менува многу пати при планирањето, изградбата и ослободувањето на софтверот, ефектот на скалирање ќе биде нула или краткотраен. Ако една организација изгради меѓуфункционални тимови околу производи кои се финансираат со фокус на пазарот, тогаш шансите за успех драстично се зголемуваат“.
„Друг важен аспект на скалирањето е прикажување на целата работа во тек (WIP, работен напредок) на таблите на Kanban. Кога една организација има место каде што луѓето можат да ги видат овие работи, тоа во голема мера ја поттикнува соработката, што има позитивно влијание врз скалирањето“.
8. Побарајте стари лузни
Мануел Паис, консултант за DevOps и коавтор на Тимски топологии: „Преземањето на практиките на DevOps надвор од самиот Dev и Ops и обидот да се применат на други функции е едвај оптимален пристап. Ова секако ќе има одредено влијание (на пример, со автоматизирање на мануелната контрола), но може да се постигне многу повеќе ако започнеме со разбирање на процесите на испорака и повратни информации“.
„Ако има стари лузни во ИТ системот на организацијата - процедури и механизми за управување што биле имплементирани како резултат на минати инциденти, но ја изгубиле својата важност (поради промени во производите, технологиите или процесите) - тогаш тие секако треба да се отстранат или измазнети, наместо автоматизирање на неефикасни или непотребни процеси“.
9. Не создавајте опции за DevOps
Ентони Едвардс, директор за операции во Eggplant: „DevOps е многу нејасен термин, така што секој тим завршува со своја верзија на DevOps. И нема ништо полошо кога една организација одеднаш има 20 варијанти на DevOps кои не се согласуваат многу добро заедно. Невозможно е секој од трите развојни тимови да има свој, посебен интерфејс помеѓу развојот и управувањето со производите. Ниту, пак, производите треба да имаат свои уникатни очекувања за справување со повратни информации кога се префрлаат на производствен симулатор. Во спротивно, никогаш нема да можете да ги зголемите DevOps.
10. Проповедајте ја деловната вредност на DevOps
Стив Њуман, основач и претседател на Scalyr: „Работете да ја препознаете вредноста на DevOps. Научете и слободно зборувајте за придобивките од она што го правите. DevOps е неверојатен заштедувач на време и пари (само помислете: помалку време на застој, пократко средно време до опоравување), а тимовите на DevOps мора неуморно да ја нагласуваат (и да ја проповедаат) важноста на овие иницијативи за деловниот успех. На овој начин можете да го проширите кругот на приврзаници и да го зголемите влијанието на DevOps во организацијата“.
БОНУС
На Нашиот сопствен DevOps ќе пристигне на 13 септември - да, Red Hat, како производител на софтвер, има свои DevOps тимови и практики.
Нашиот инженер Марк Биргер, кој развива услуги за внатрешна автоматизација за други групи низ организацијата, ќе ја раскаже својата приказна на чист руски јазик - како тимот на Red Hat DevOps мигрирал апликации од виртуелните средини за виртуелизација на Hat управувани од Ansible во полноправно формат на контејнер на платформата OpenShift.
Но, тоа не е се:
Откако организациите ќе го преместат обемот на работа во контејнери, традиционалните методи за следење на апликациите можеби нема да работат. Во вториот разговор ќе ја објасниме нашата мотивација за промена на начинот на евидентирање и ќе го покажеме продолжувањето на патеката што не доведе до современи методи за сеча и следење.
Извор: www.habr.com