Пречките, които спират DevOps: култура, доставка и сигурност

Идеята за непрекъснато доставян качествен софтуер, проверен чрез съвместна и силно автоматизирана поредица от стъпки от създаването до внедряването, е примамлива, оттук и привлекателността на DevOps. Въпреки това, докато почти всички казват, че преследват DevOps, реалността на място е в най-добрия случай смесена.

Неотложността на DevOps само се увеличи през последната година, тъй като кризата с Covid разпръсна корпоративната работна сила и физически раздели ИТ екипите. „Трябва да преосмислим връзките и интеграциите, както на техническо, така и на човешко ниво“, казва

Ед Макоски, началник продукт в Буми ."Въпреки че може да изглежда, че много екипи на DevOps нямат никакви проблеми да работят от разстояние, двама от петима казват, че отдалечената работа е засяга способността им да правят иновации и да бъдат креативни, като мнозинството отбелязва, че това се дължи на липсата на лична връзка с колеги. Екипите на DevOps вдъхват живот на иновациите в една компания."

Въпреки това беше трудно да се организират и поддържат DevOps екипи, особено в този момент на несигурност. „С напускането на служителите екипите на DevOps често са оставени да се справят с пожар, базиран на скрипт,“ предупреждава Ашиш Къкран, директор с Thomvest Ventures. Например, докато DevOps трябва да постави разработката и операциите на една и съща страница, двете групи често все още поемат по свои отделни пътища. „Виждаме DevOps, внедрен отделно и по различен начин в различни функционални области на една и съща организация“, казва Браян Доусън, DevOps евангелист с CloudBees. „Операциите могат да прилагат свои собствени инструменти и процеси DevOps, докато разработката на приложения внедрява свои собствени инструменти и процеси DevOps.“

• Изпълнително ръководство за гъвкаво развитие и ИТ операции

Така че докато възприятието на място е, че всички правят DevOps, „реалността също е, че все още имаме работа, за да го направим правилно, да го направим в мащаб и да постигнем универсална зрялост“, добавя Доусън. „DevOps е за свързване на разработката и операциите. Предизвикателството е да се изградят тези връзки, универсално, между лидери и практици, Dev и Ops."

Културните проблеми създават тази несвързана връзка между Dev и Ops. „Културата е липсващият компонент номер едно, но има и неуспех за истинско свързване и автоматизиране във функционалните силози“, казва Доусън. „Това води до липса на споделена видимост, последователна обратна връзка за стимулиране на подобрение и, потенциално, отрицателен опит, който възпрепятства приемането.“

Има твърде много инструменти, които се състезават и за споделянето на ума на екипите за разработка и операции. „Един екип може да има между 20 и 50 инструмента“, казва Какран. „Разделянето на сигнала от шума, когато сте бомбардирани от стотици сигнали на час, е доста предизвикателство.“

Частта за непрекъсната доставка също е пречка в непрекъснатата интеграция/непрекъсната доставка (CI/CD), която трябва да протича без усилие през DevOps. „Предприятията изостават в автоматизацията на тестовете и увеличават усилията си за автоматизиране на непрекъснатото тестване, което е основен компонент на CD“, казва Венки Ченапрагада, DevOps архитект с Capgemini Северна Америка.. „Някои предприятия не могат да възприемат високо ниво на CI/CD, тъй като тяхното портфолио от приложения се състои предимно от пакетиран софтуер, наследен софтуер или ERP системи.“

Сигурността е друг проблем, който забавя практиките на DevOps. „Съвременната DevOps среда е пълна с креативни хора, които са насърчавани да изграждат бързи и трудни за постигане цели за иновации“, казва Кевин Брийн, директор на отдела за изследване на кибернетични заплахи в Потапящи лаборатории. „Проблемът е, че екипите по сигурността се намесват само в края на CI/CD тръбопровода и посочват уязвимостите. Често това е след като кодът е бил ангажиран, а понякога дори след като разработчикът е преминал към друга компилация." В резултат на твърде късното навлизане на екипи, ориентирани към сигурността, "това причинява търкания и унищожава производителността, тъй като означава, че ресурсите се изтеглят." 

Това, което се пропуска с усилията на DevOps, добавя Ченапрагада, е силното управление. Това "води до множество версии на реализации и конвейери." Тези работни процеси, продължава той, „трябва да бъдат изградени на базата върху шаблони, така че да са лесни за възпроизвеждане, което води до по-добра поддръжка и поддръжка, които могат да бъдат изпълнени от инженерите на DevOps."

Какво може да се направи, за да стане DevOps по-сплотен и трансформиращ? Индустриалните мислители дават някои предложения, за да накараме нещата да се оправят:

• Прехвърлете повече отговорност на разработчиците. Да, DevOps не винаги е предложение 50/50. Kakran призовава за ускоряване на феномена "Shift-Left", което поставя повече отговорност за процеса в ръцете на разработчиците. „В този свят инструментите за разработка, запълващи категорията „X-as-Code“, ще имат огромно въздействие върху способността на организацията да доставя по-бързо, по-често и с по-малък брой неуспешни внедрявания," той казва. „„X“ тук е критичен компонент на приложението – инфраструктура, сигурност, съответствие и други. Тази комбинация от по-овластени разработчици и по-ефективни DevOps инструменти драстично ще ускори доставката на софтуер дори повече от миналото."

• Насърчавайте повече обучение, образование и осведоменост за DevOps. „DevOps и екипите по сигурността трябва да намалят напрежението чрез развитие на умения“, казва Брийн. „Като насаждаме инженерите с разбиране за основните принципи на сигурността и постепенно им помагаме разбират повече технически нюанси, те ще започнат да разработват по-сигурен код като част от ежедневието си работа. Това намалява триенето, спира извикването на код и помага на иновациите да процъфтяват."

• Свържете DevOps с крайния клиент. „Виждаме по-голям успех в предприятия, където има шампион на DevOps на ниво CX, който може да премахне пречките, дължащи се на проблеми с културата, процесите или инструментите, когато възникнат“, казва Ченапрагада.

• Наблюдавайте пазара за по-интегрирани решения. „Интегрираните DevOps платформи от край до край ще станат норма“, казва Какран. „Такива платформи ще предложат няколко най-добри в класа си компонента с вградена автоматизация и ще позволят на организациите да интегрират други DevOps инструменти по plug and play начин. Сливанията и придобиванията ще се ускорят през 2021 г., като по-големите компании ще бързат да придобият по-малки компании, които разполагат с най-добрите в класа инструменти, които биха им помогнали да осигурят интегрирана решение." В резултат на това, казва той, „директорите по информационни технологии ще могат драстично да подобрят производителността на своите екипи, като оставят проблемите с интегрирането и поддръжката на CI/CD тръбопроводите на интегрираните платформи. Тенденцията вътрешните екипи да пишат скриптове или генерират билети ще бъдат заменени от автоматизация, осигурена от интегрирани инструменти от доставчици на трети страни, ще се ускори значително през 2021 г."

• Общувайте повече. „Ключово е, че DevOps разполага с инструментите и ресурсите, за да продължи да създава и бързо да интегрира“, казва Макоски. „Това се свежда до подобрени комуникации и използване на инструменти за пестене на време като нисък код. Нови идеи могат да възникнат, когато сме свързани. Тогава можем да разрешим повече проблеми и отборите могат да надделеят, независимо от ситуацията."

В крайна сметка, през следващите месеци и години, „приемането на базирани на облак, базирани на контейнери микросервизни архитектури налага приемането на DevOps култура и инструменти, казва Какран. „По-новите приложения се изграждат изцяло с помощта на контейнери и Kubernetes и се хостват в хибридна облачна среда. Това важи дори за най-големите финансови институции, които исторически са се колебали да приемат облака. Повдигането и преместването на наследени приложения е по-труден за решаване проблем, но дори там се полагат сериозни усилия, тъй като ползите от облака надвишават разходите за приемане. 2021 ще бъде годината на известност за 50-те милиона разработчици на софтуер по света, доставящи софтуер с много висока скорост с по-високо качество от всякога."