Трудно ли е да се разбере основната точка, когато говорим за DevOps? Събрахме за вас ярки аналогии, поразителни формулировки и съвети от експерти, които ще помогнат дори на неспециалистите да стигнат до същността. В крайна сметка бонусът е DevOps на служителите на Red Hat.
Терминът DevOps възниква преди 10 години и се превърна от хаштаг в Twitter до мощно културно движение в ИТ света, истинска философия, която насърчава разработчиците да вършат нещата по-бързо, да експериментират и да продължават напред. DevOps стана неразривно свързан с концепцията за цифрова трансформация. Но както често се случва с ИТ терминологията, през последните десет години DevOps придоби много дефиниции, интерпретации и погрешни схващания за себе си.
Ето защо често можете да чуете въпроси за DevOps като, същото ли е като agile? Или това е някаква специална методика? Или е просто още един синоним на думата „сътрудничество“?
DevOps включва много различни концепции (непрекъснато доставяне, непрекъсната интеграция, автоматизация и т.н.), така че дестилирането на това, което е важно, може да бъде предизвикателство, особено когато сте запалени по темата. Това умение обаче е много полезно, независимо дали се опитвате да предадете идеите си на началниците си или просто да разкажете на някой от семейството или приятелите си за работата си. Затова нека засега оставим настрана терминологичните нюанси на DevOps и да се съсредоточим върху голямата картина.
Какво е DevOps: 6 дефиниции и аналогии
Помолихме експертите да обяснят същността на DevOps възможно най-просто и накратко, така че стойността му да стане ясна за читателите с всяко ниво на технически познания. Въз основа на резултатите от тези разговори ние избрахме най-впечатляващите аналогии и удивителни формулировки, които ще ви помогнат да изградите своята история за DevOps.
1. DevOps е културно движение
„DevOps е културно движение, в което и двете страни (разработчици на софтуер и специалисти по работа на ИТ системи) признават, че софтуерът не носи реални ползи, докато някой не започне да го използва: клиенти, клиенти, служители, не е важното“, казва Евелин Ерлих, старши изследовател анализатор в DevOps Institute. „Следователно и двете страни гарантират съвместно бърза и висококачествена доставка на софтуер.“
2. DevOps е за овластяване на разработчиците.
„DevOps дава възможност на разработчиците да притежават приложения, да ги изпълняват и да управляват доставката от началото до края.“
„Обикновено за DevOps се говори като за начин за ускоряване на доставката на приложения до производство чрез изграждане и внедряване на автоматизирани процеси“, казва Джай Шниеп, директор на платформите DevOps в застрахователната компания Liberty Mutual. „Но за мен това е много по-фундаментално нещо.“ DevOps дава възможност на разработчиците да притежават приложения или конкретни софтуерни части, да ги изпълняват и да управляват доставката им от началото до края. DevOps елиминира объркването на отговорността и напътства всички, участващи в създаването на автоматизирана инфраструктура, управлявана от разработчиците.“
3. DevOps е за сътрудничество при създаване и доставяне на приложения.
„Най-просто казано, DevOps е подход към производството и доставката на софтуер, при който всички работят заедно“, казва Гур Стаф, президент и ръководител на дигиталната бизнес автоматизация в BMC.
4. DevOps е тръбопровод
„Сглобяването на конвейера е възможно само ако всички части пасват една към друга.“
„Бих сравнил DevOps с поточна линия за автомобили“, продължава Gur Staff. – Идеята е всички части да се проектират и изработят предварително, за да могат след това да се сглобяват без индивидуална настройка. Сглобяването на конвейера е възможно само ако всички части пасват една към друга. Тези, които проектират и конструират двигател, трябва да обмислят как да го монтират към тялото или рамата. Тези, които правят спирачките, трябва да мислят за колелата и т.н. Същото трябва да е вярно и със софтуера.
Разработчикът, създаващ бизнес логика или потребителски интерфейс, трябва да помисли за базата данни, която съхранява информация за клиентите, мерките за сигурност за защита на потребителските данни и как всичко това ще работи, когато услугата започне да обслужва голяма, може би дори многомилионна потребителска аудитория ."
„Да накараш хората да си сътрудничат и да мислят за частите от работата, които другите вършат, вместо да се фокусират единствено върху собствените си задачи, е най-голямата пречка за преодоляване. Ако успеете да направите това, имате отличен шанс за дигитална трансформация“, добавя Gur Staff.
5. DevOps е правилната комбинация от хора, процеси и автоматизация
Jayne Groll, изпълнителен директор на DevOps Institute, предложи страхотна аналогия, за да обясни DevOps. По нейните думи „DevOps е като рецепта с три основни категории съставки: хора, процес и автоматизация. Повечето от тези съставки могат да бъдат взети от други области и източници: Lean, Agile, SRE, CI/CD, ITIL, лидерство, култура, инструменти. Тайната на DevOps, като всяка добра рецепта, е как да получите правилните пропорции и смес от тези съставки, за да увеличите скоростта и ефективността на създаване и пускане на приложения.
6. DevOps е, когато програмистите работят като отбор от Формула 1
„Състезанието не е планирано от началото до края, а напротив, от финала до старта.“
„Когато говоря за това какво да очаквам от инициатива DevOps, мисля за състезателен отбор NASCAR или Формула 1 като пример“, казва Крис Шорт, старши мениджър маркетинг на облачна платформа в Red Hat и издател на бюлетина на DevOps. – Лидерът на такъв отбор има една цел: да заеме възможно най-високото място в края на състезанието, като вземе предвид ресурсите, с които разполага отборът и предизвикателствата, които го сполетяха. В този случай състезанието се планира не от старт до финал, а напротив, от финал до старт. Първо се поставя амбициозна цел, а след това се определят начините за нейното постигане. След това те се разделят на подзадачи и се делегират на членовете на екипа.“
„Отборът прекарва цялата седмица преди състезанието, усъвършенствайки питстопа. Той прави силови и кардио тренировки, за да остане във форма за един изтощителен състезателен ден. Практикува съвместна работа за решаване на проблеми, които могат да възникнат по време на състезанието. По същия начин екипът за разработка трябва да тренира уменията за често пускане на нови версии. Ако имате такива умения и добре работеща система за сигурност, пускането на нови версии в производство също се случва по-често. В този мироглед повишената скорост означава повишена безопасност“, казва Шорт.
„Не става въпрос да правим „правилното нещо“, добавя Шорт, „а да елиминираме възможно най-много неща, които пречат на желания резултат. Сътрудничете и се адаптирайте въз основа на обратната връзка, която получавате в реално време. Бъдете подготвени за аномалии и работете за подобряване на качеството, за да минимизирате въздействието им върху напредъка към вашата цел. Това е, което ни очаква в света на DevOps.”
Как да мащабирате DevOps: 10 съвета от експерти
Просто DevOps и масовите DevOps са напълно различни неща. Ще ви кажем как да преодолеете бариерите по пътя от първото към второто.
За много организации пътуването до DevOps започва лесно и приятно. Създават се малки страстни екипи, старите процеси се заменят с нови и първите успехи не закъсняват.
Уви, това е само фалшив блясък, илюзия за напредък, казва Бен Гринел, управляващ директор и ръководител на дигиталния отдел в консултантската компания North Highland. Ранните победи със сигурност са окуражаващи, но те не помагат за постигането на крайната цел за широко приемане на DevOps в цялата организация.
Лесно е да се види, че резултатът е култура на разделение между „ние“ и „те“.
„Често организациите стартират тези пионерски проекти, като си мислят, че ще проправят пътя към основните DevOps, без да обмислят дали другите ще могат или желаят да следват този път“, обяснява Бен Гринел. – Екипите за изпълнение на такива проекти обикновено се набират от самоуверени „варяги“, които вече са правили нещо подобно на други места, но са нови за вашата организация. В същото време те се насърчават да нарушават и унищожават правилата, които остават задължителни за всички останали. Лесно е да се види, че резултатът е култура на „ние“ и „те“, която възпрепятства трансфера на знания и умения.“
„И този културен проблем е само една от причините DevOps да е труден за мащабиране. Екипите на DevOps са изправени пред нарастващи технически предизвикателства, които са типични за бързо развиващите се компании, които са на първо място в ИТ“, каза Стив Нюман, основател и председател на Scalyr.
„В съвременния свят услугите се променят веднага щом възникне необходимост. Страхотно е постоянно да внедряваш и прилагаш нови функции, но координирането на този процес и премахването на възникващите проблеми е истинско главоболие, добавя Стив Нюман. – В много бързо развиващи се организации инженерите в многофункционални екипи се борят да запазят видимостта на промяната и каскадните ефекти на ниво зависимост, които тя създава. Освен това инженерите не са доволни, когато са лишени от тази възможност и в резултат на това им става по-трудно да разберат същността на възникващите проблеми.
Как да преодолеем тези предизвикателства, описани по-горе, и да преминем към масово приемане на DevOps в голяма организация? Експертите призовават към търпение, дори ако крайната ви цел е да ускорите цикъла на разработка на софтуер и бизнес процесите.
1. Не забравяйте, че промяната на културата отнема време.
Джейн Грол, изпълнителен директор, DevOps Institute: „По мое мнение, разширяването на DevOps трябва да бъде толкова постепенно и итеративно, колкото и гъвкавото развитие (и също толкова засягащо културата). Agile и DevOps наблягат на малките екипи. Но тъй като тези екипи нарастват по брой и интеграция, в крайна сметка получаваме повече хора, възприемащи нови начини на работа, и в резултат на това има масивна културна трансформация.“
2. Отделете достатъчно време за планиране и избор на платформа
Еран Кинсбрунер, водещ технически евангелист в Perfecto: „За да работи мащабирането, екипите на DevOps трябва първо да се научат да комбинират традиционни процеси, инструменти и умения и след това бавно да подхранват и стабилизират всяка отделна фаза на DevOps. Всичко започва с внимателно планиране на потребителски истории и потоци от стойност, последвано от писане на софтуер и контрол на версиите, използвайки базирана на магистрала разработка или други подходи, най-подходящи за разклоняване и сливане на код.“
„След това идва етапът на интегриране и тестване, където вече е необходима мащабируема платформа за автоматизация. Тук е важно за екипите на DevOps да изберат правилната платформа, която отговаря на тяхното ниво на умения и крайните цели на проекта.
Следващата фаза е внедряването в производството и това трябва да бъде напълно автоматизирано с помощта на инструменти за оркестрация и контейнери. Важно е да имате виртуализирани среди на всички етапи на DevOps (симулатор на производство, QA среда и действителна производствена среда) и винаги да използвате само най-новите данни за тестове, за да получите подходящи заключения. Анализът трябва да е интелигентен и способен да обработва големи данни с бърза и ефективна обратна връзка.“
3. Премахнете вината от отговорност.
Гордън Хаф, евангелист на RedHat: „Създаването на система и атмосфера, която позволява и насърчава експериментирането, позволява това, което е известно като успешни провали в гъвкавото разработване на софтуер. Това не означава, че никой друг не носи отговорност за провалите. Всъщност идентифицирането на отговорния става още по-лесно, тъй като „да си отговорен“ вече не означава „да причиниш злополука“. Тоест същността на отговорността се променя качествено. Четири фактора стават критични: степента на прекъсване, подходи, производствени процеси и стимули.“ (Можете да прочетете повече за тези фактори в статията на Гордън Хъф „Уроци по DevOps: 4 аспекта на здравословните експерименти.“)
4. Разчистете пътя напред
Бен Гринел, управляващ директор и ръководител на дигиталния отдел в консултантската компания North Highland: „За постигане на мащаб препоръчвам стартирането на програма за „разчистване на пътя“ заедно с пионерски проекти. Целта на тази програма е да изчисти боклука, който пионерите на DevOps оставят след себе си, като остарели правила и подобни неща, така че пътят напред да остане ясен.“
„Дайте на хората организационна подкрепа и инерция чрез комуникация, която надхвърля пионерската група, като широко празнувате успехите на новите начини на работа. Обучете хора, които участват в следващата вълна от проекти DevOps и са нервни да използват DevOps за първи път. И не забравяйте, че тези хора са много различни от пионерите.
5. Демократизирайте инструментите
Стив Нюман, основател и председател на Scalyr: „Инструментите не трябва да се крият от хората и те трябва да бъдат относително лесни за научаване за всеки, който желае да отдели време. Ако възможността за заявки за регистрационни файлове е ограничена до трима души, „сертифицирани“ да използват инструмент, винаги ще имате на разположение максимум трима души, които да се справят с проблема, дори ако имате много голяма компютърна среда. С други думи, тук има пречка, която може да доведе до сериозни (бизнес) последствия.“
6. Създайте идеални условия за работа в екип
Том Кларк, ръководител на Common Platform в ITV: „Можеш да направиш всичко, но не всичко наведнъж. Затова си поставяйте големи цели, започнете с малко и вървете напред с бързи повторения. С течение на времето ще придобиете репутация на човек, който върши нещата, така че другите също ще искат да използват вашите методи. И не се притеснявайте за изграждането на високоефективен екип. Вместо това осигурете на хората идеални условия за работа и ефективността ще последва."
7. Не забравяйте за дъските Закон на Конуей и Канбан
Логан Дейгъл, директор по доставка на софтуер и стратегия за DevOps в CollabNetVersionOne: „Важно е да разберем последствията от закона на Конуей. В моя свободен перифраз, този закон гласи, че продуктите, които създаваме, и процесите, които използваме за това, включително DevOps, се оказват структурирани по същия начин като нашата организация.“
„Ако има много силози в една организация и контролът сменя ръцете си много пъти при планиране, изграждане и пускане на софтуер, ефектът от мащабирането ще бъде нулев или краткотраен. Ако една организация изгради многофункционални екипи около продукти, които са финансирани с пазарен фокус, тогава шансовете за успех нарастват драстично.“
„Друг важен аспект на мащабирането е показването на цялата текуща работа (WIP, workinprogress) на Kanban дъски. Когато една организация има място, където хората могат да видят тези неща, това силно насърчава сътрудничеството, което има положително въздействие върху мащабирането.“
8. Търсете стари белези
Мануел Паис, DevOps консултант и съавтор на Team Topologies: „Извеждането на практиките на DevOps отвъд самия Dev and Ops и опитът да се приложат към други функции едва ли е оптимален подход. Това със сигурност ще има известно въздействие (например чрез автоматизиране на ръчното управление), но може да се постигне много повече, ако започнем с разбиране на процесите на доставка и обратна връзка.“
„Ако има стари белези в ИТ системата на една организация – процедури и механизми за управление, които са били внедрени в резултат на минали инциденти, но са загубили своята релевантност (поради промени в продукти, технологии или процеси) – тогава те със сигурност трябва да бъдат премахнати или изгладени, вместо автоматизиране на неефективни или ненужни процеси.“
9. Не създавайте DevOps опции
Антъни Едуардс, директор операции в Eggplant: „DevOps е много неясен термин, така че всеки екип завършва със собствена версия на DevOps. И няма нищо по-лошо, когато една организация изведнъж има 20 разновидности на DevOps, които не се разбират много добре заедно. Невъзможно е всеки от трите екипа за разработка да има свой собствен, специален интерфейс между разработката и управлението на продукта. Нито продуктите трябва да имат свои собствени уникални очаквания за обработка на обратна връзка, когато се прехвърлят към производствен симулатор. В противен случай никога няма да можете да мащабирате DevOps.“
10. Проповядвайте бизнес стойността на DevOps
Стив Нюман, основател и председател на Scalyr: „Работете, за да разпознаете стойността на DevOps. Научете се и се чувствайте свободни да говорите за ползите от това, което правите. DevOps е невероятна спестяваща време и пари (само помислете: по-малко престой, по-кратко средно време за възстановяване) и екипите на DevOps трябва неуморно да подчертават (и проповядват) важността на тези инициативи за успеха на бизнеса. По този начин можете да разширите кръга от привърженици и да увеличите влиянието на DevOps в организацията.
BONUS
На Нашият собствен DevOps ще пристигне на 13 септември - да, Red Hat, като производител на софтуер, има свои собствени екипи и практики за DevOps.
Нашият инженер Марк Биргер, който разработва вътрешни услуги за автоматизация за други групи в цялата организация, ще разкаже собствената си история на чист руски език - как екипът на Red Hat DevOps мигрира приложения от виртуални среди на Hat Virtualization, управлявани от Ansible, към пълноценен контейнерен формат на платформата OpenShift.
Но това не е всичко:
След като организациите преместят работните натоварвания в контейнери, традиционните методи за наблюдение на приложения може да не работят. Във втората лекция ще обясним мотивацията си да променим начина, по който регистрираме и ще покажем продължаването на пътя, който ни доведе до съвременни методи за регистриране и мониторинг.
Източник: www.habr.com