DevOps haqqında danışarkən əsas məqamı başa düşmək çətindir? Biz sizin üçün hətta qeyri-mütəxəssislərə də mətləblərə çatmağa kömək edəcək parlaq bənzətmələri, heyrətamiz formulaları və ekspertlərin məsləhətlərini topladıq. Sonda bonus Red Hat işçilərinin öz DevOpsudur.
DevOps termini 10 il əvvəl yaranıb və Twitter hashtagından İT dünyasında güclü mədəni hərəkata, tərtibatçıları işləri daha sürətli etməyə, sınaqdan keçirməyə və irəliləməyə təşviq edən əsl fəlsəfəyə çevrilib. DevOps rəqəmsal transformasiya konsepsiyası ilə ayrılmaz şəkildə bağlı olmuşdur. Lakin İT terminologiyasında tez-tez baş verdiyi kimi, son on il ərzində DevOps özü haqqında çoxlu təriflər, şərhlər və yanlış təsəvvürlər əldə etmişdir.
Buna görə də, siz tez-tez DevOps haqqında suallar eşidə bilərsiniz, bu çevik ilə eynidirmi? Yoxsa bu hansısa xüsusi metodologiyadır? Yoxsa "əməkdaşlıq" sözünün başqa sinonimidir?
DevOps bir çox fərqli anlayışları (davamlı çatdırılma, davamlı inteqrasiya, avtomatlaşdırma və s.) ehtiva edir, buna görə də vacib olanı ayırmaq çətin ola bilər, xüsusən də mövzuya həvəsli olduğunuz zaman. Ancaq fikirlərinizi rəhbərlərinizə çatdırmağa çalışmağınızdan və ya sadəcə ailənizdən və ya dostlarınızdan kiməsə işiniz haqqında danışmağınızdan asılı olmayaraq, bu bacarıq çox faydalıdır. Buna görə də, gəlin indilik DevOps-un terminoloji nüanslarını bir kənara qoyub böyük mənzərəyə diqqət yetirək.
DevOps nədir: 6 Təriflər və Analogiyalar
Mütəxəssislərdən DevOps-un mahiyyətini mümkün qədər sadə və qısa şəkildə izah etmələrini xahiş etdik ki, onun dəyəri istənilən texniki biliyə malik oxuculara aydın olsun. Bu söhbətlərin nəticələrinə əsasən, biz DevOps haqqında hekayənizi qurmağınıza kömək edəcək ən təəccüblü analogiyaları və heyrətamiz formulaları seçdik.
1. DevOps mədəni hərəkatdır
“DevOps hər iki tərəfin (proqram təminatı tərtibatçıları və İT sistemi əməliyyatları üzrə mütəxəssislər) kiminsə ondan istifadə etməyə başlamasına qədər proqramın real fayda gətirmədiyini qəbul etdiyi mədəni hərəkatdır: müştərilər, müştərilər, işçilər, əsas deyil,” Eveline Oehrlich, baş tədqiqatçı deyir. DevOps İnstitutunda analitik. “Buna görə də bu tərəflərin hər ikisi birlikdə proqram təminatının sürətli və keyfiyyətli çatdırılmasını təmin edirlər”.
2. DevOps tərtibatçıları gücləndirməkdən ibarətdir.
"DevOps tərtibatçılara proqramlara sahib olmaq, onları işə salmaq və başdan sona çatdırılmanı idarə etmək imkanı verir."
Liberty Mutual sığorta şirkətinin DevOps platformalarının direktoru Jai Schniepp deyir: "Adətən DevOps, avtomatlaşdırılmış proseslərin qurulması və həyata keçirilməsi ilə tətbiqlərin istehsala çatdırılmasını sürətləndirməyin bir yolu kimi danışılır". "Ancaq mənim üçün bu, daha əsas şeydir." DevOps tərtibatçılara proqramlara və ya xüsusi proqram hissələrinə sahib olmaq, onları işə salmaq və onların çatdırılmasını başdan sona idarə etmək imkanı verir. DevOps məsuliyyət çaşqınlığını aradan qaldırır və avtomatlaşdırılmış, tərtibatçı tərəfindən idarə olunan infrastrukturun yaradılmasında iştirak edən hər kəsə rəhbərlik edir.”
3. DevOps proqramların yaradılması və çatdırılmasında əməkdaşlıq haqqındadır.
“Sadə dillə desək, DevOps hər kəsin birlikdə işlədiyi proqram təminatının istehsalı və çatdırılmasına yanaşmadır,” BMC-nin rəqəmsal biznesin avtomatlaşdırılması üzrə prezidenti və rəhbəri Gur Staf deyir.
4. DevOps bir boru kəməridir
“Konveyerin yığılması yalnız bütün hissələrin bir-birinə uyğunlaşdığı halda mümkündür.”
"Mən DevOps-u avtomobil yığım xətti ilə müqayisə edərdim" deyə Gur Heyəti davam edir. – İdeya ondan ibarətdir ki, bütün hissələri əvvəlcədən fərdi qaydada tənzimləmədən yığmaq mümkün olsun. Konveyerin yığılması yalnız bütün hissələri bir-birinə uyğunlaşdıqda mümkündür. Mühərriki dizayn edən və hazırlayanlar onu gövdəyə və ya çərçivəyə necə quraşdırmaq barədə düşünməlidirlər. Əyləc edənlər təkərlər haqqında düşünməlidirlər və s. Eyni şey proqram təminatı ilə də keçməlidir.
Biznes məntiqi və ya istifadəçi interfeysi yaradan tərtibatçı müştəri məlumatlarını saxlayan verilənlər bazası, istifadəçi məlumatlarını qorumaq üçün təhlükəsizlik tədbirləri və xidmət böyük, bəlkə də çoxmilyonlarla dollarlıq istifadəçi auditoriyasına xidmət etməyə başlayanda bütün bunların necə işləyəcəyi barədə düşünməlidir. ."
“İnsanları əməkdaşlıq etməyə və yalnız öz işlərinə diqqət yetirməkdənsə, başqalarının gördükləri işin hissələri haqqında düşünməyə məcbur etmək, aradan qaldırılması üçün ən böyük maneədir. Bunu edə bilsəniz, rəqəmsal transformasiya üçün əla şansınız var "deyə Gur Staff əlavə edir.
5. DevOps insanların, proseslərin və avtomatlaşdırmanın düzgün birləşməsidir
DevOps İnstitutunun icraçı direktoru Jayne Groll, DevOps-u izah etmək üçün böyük bir bənzətmə təklif etdi. Onun sözləri ilə desək, “DevOps üç əsas inqrediyent kateqoriyası olan reseptə bənzəyir: insanlar, proses və avtomatlaşdırma. Bu inqrediyentlərin əksəriyyəti digər sahələrdən və mənbələrdən götürülə bilər: Lean, Agile, SRE, CI/CD, ITIL, liderlik, mədəniyyət, alətlər. DevOps-un sirri, hər hansı yaxşı resept kimi, proqramların yaradılması və buraxılmasının sürətini və səmərəliliyini artırmaq üçün bu inqrediyentlərin düzgün nisbətlərini və qarışığını necə əldə etməkdir.”
6. DevOps proqramçıların Formula 1 komandası kimi işləməsidir
"Yarış əvvəldən sona qədər deyil, əksinə, finişdən starta qədər planlaşdırılır."
Red Hat-ın bulud platforması marketinqi üzrə baş meneceri və DevOps'ish bülleteninin naşiri Chris Short deyir: "Mən DevOps təşəbbüsündən nə gözləyəcəyim haqqında danışarkən, NASCAR və ya Formula 1 yarış komandasını nümunə kimi düşünürəm". – Belə komandanın liderinin bir məqsədi var: yarışın sonunda komandanın mövcud resurslarını və onun üzləşdiyi çətinlikləri nəzərə alaraq mümkün olan ən yüksək yeri tutmaq. Bu halda yarış başdan sona deyil, əksinə, finişdən starta qədər planlaşdırılır. Əvvəlcə qarşıya iddialı məqsəd qoyulur, sonra isə ona çatmağın yolları müəyyənləşdirilir. Sonra onlar alt tapşırıqlara bölünür və komanda üzvlərinə həvalə edilir.”
“Komanda yarışdan əvvəl bütün həftəni pit-stopu mükəmməlləşdirmək üçün sərf edir. O, yorucu yarış günündə formada qalmaq üçün güc məşqləri və kardiyo ilə məşğul olur. Yarış zamanı yarana biləcək problemləri həll etmək üçün birlikdə işləməyi məşq edir. Eynilə, inkişaf komandası tez-tez yeni versiyaları buraxmaq bacarığını öyrətməlidir. Əgər belə bacarıqlarınız və yaxşı işləyən təhlükəsizlik sisteminiz varsa, yeni versiyaların istehsala buraxılması da daha tez-tez baş verir. Bu dünyagörüşündə sürətin artması təhlükəsizliyin artması deməkdir” Şort deyir.
"Bu," düzgün olanı " etmək deyil," Şort əlavə edir, "istənilən nəticəyə mane olan mümkün qədər çox şeyi aradan qaldırmaqdır. Real vaxtda aldığınız rəy əsasında əməkdaşlıq edin və uyğunlaşın. Anormallıqlara hazır olun və məqsədinizə doğru irəliləyişlərə təsirini minimuma endirmək üçün keyfiyyəti yaxşılaşdırmağa çalışın. Bu bizi DevOps dünyasında gözləyən şeydir.”
DevOps-u necə genişləndirmək olar: ekspertlərdən 10 məsləhət
Sadəcə, DevOps və kütləvi DevOps tamamilə fərqli şeylərdir. Birincidən ikinciyə gedən yolda maneələri necə dəf edəcəyinizi sizə xəbər verəcəyik.
Bir çox təşkilat üçün DevOps-a səyahət asan və xoş başlayır. Kiçik ehtiraslı komandalar yaradılır, köhnə proseslər yeniləri ilə əvəz olunur və ilk uğurlar özünü çox gözlətmir.
Təəssüf ki, bu, sadəcə olaraq saxta parıltı, tərəqqi illüziyasıdır, deyə North Highland konsaltinq şirkətinin idarəedici direktoru və rəqəmsal rəhbəri Ben Grinnell deyir. Erkən qalibiyyətlər, şübhəsiz ki, həvəsləndiricidir, lakin onlar DevOps-un təşkilat daxilində geniş şəkildə mənimsənilməsi kimi əsas məqsədə çatmağa kömək etmir.
Bunun nəticəsinin “biz” və “onlar” arasında bölünmə mədəniyyəti olduğunu görmək asandır.
Ben Grinnell izah edir: "Çox vaxt təşkilatlar başqalarının bu yolu izləyə biləcəyini və ya istəyə biləcəyini nəzərə almadan, əsas DevOps-a yol açacaqlarını düşünərək bu qabaqcıl layihələri işə salırlar". – Bu cür layihələri həyata keçirmək üçün komandalar adətən başqa yerlərdə oxşar işləri görmüş, lakin təşkilatınız üçün yeni olan özünə güvənən “Varanqiyalılar”dan seçilir. Eyni zamanda, hər kəs üçün məcburi qalan qaydaları pozmağa və məhv etməyə təşviq olunurlar. Nəticənin bilik və bacarıqların ötürülməsinə mane olan “biz” və “onların” mədəniyyəti olduğunu görmək asandır”.
“Və bu mədəni problem DevOps-un miqyasının çətin olmasının səbəblərindən biridir. DevOps komandaları sürətlə böyüyən İT şirkətləri üçün xarakterik olan artan texniki çətinliklərlə üzləşir”, - Scalyr-in təsisçisi və sədri Stiv Nyuman bildirib.
“Müasir dünyada xidmətlər ehtiyac yaranan kimi dəyişir. Davamlı olaraq yeni funksiyaların tətbiqi və tətbiqi əladır, lakin bu prosesi əlaqələndirmək və yaranan problemləri aradan qaldırmaq əsl başağrısıdır, Steve Newman əlavə edir. – Çox sürətlə böyüyən təşkilatlarda çarpaz funksional komandalardakı mühəndislər dəyişikliyə və onun asılılıq səviyyəsində yaratdığı kaskad effektlərə görünmə qabiliyyətini saxlamaq üçün mübarizə aparırlar. Üstəlik, mühəndislər bu imkandan məhrum olanda sevinmirlər və nəticədə ortaya çıxan problemlərin mahiyyətini anlamaq çətinləşir”.
Yuxarıda təsvir olunan bu çətinlikləri necə aradan qaldırmaq və DevOps-un böyük bir təşkilatda kütləvi şəkildə mənimsənilməsinə keçmək olar? Mütəxəssislər, son məqsədiniz proqram təminatının inkişaf dövrünü və biznes proseslərini sürətləndirmək olsa belə, səbirli olmağa çağırır.
1. Unutmayın ki, mədəniyyət dəyişikliyi vaxt tələb edir.
Jayne Groll, DevOps İnstitutunun icraçı direktoru: “Məncə, DevOps-un genişlənməsi çevik inkişaf kimi artımlı və iterativ olmalıdır (və eyni dərəcədə mədəniyyətə də toxunur). Agile və DevOps kiçik komandaları vurğulayır. Lakin bu komandaların sayı və inteqrasiyası artdıqca, biz daha çox insanın yeni iş üsullarını mənimsəməsi ilə nəticələnirik və nəticədə kütləvi mədəni transformasiya baş verir”.
2. Planlaşdırmağa və platforma seçməyə kifayət qədər vaxt ayırın
Eran Kinsbruner, Perfecto-da Baş Texniki Evangelist: “İşləmək üçün miqyası artırmaq üçün DevOps komandaları əvvəlcə ənənəvi prosesləri, alətləri və bacarıqları birləşdirməyi öyrənməli, sonra yavaş-yavaş DevOps-un hər bir fərdi mərhələsini inkişaf etdirməli və sabitləşdirməlidir. Hamısı istifadəçi hekayələrinin və dəyər axınının diqqətlə planlaşdırılmasından başlayır, ardınca magistral əsaslı inkişafdan və ya kodun budaqlanması və birləşdirilməsi üçün ən uyğun olan digər yanaşmalardan istifadə edərək proqram təminatı və versiyaya nəzarətin yazılması ilə başlayır.”
“Sonra inteqrasiya və sınaq mərhələsi gəlir, burada avtomatlaşdırma üçün genişləndirilə bilən platforma artıq tələb olunur. Bu, DevOps komandalarının bacarıq səviyyələrinə və layihənin son məqsədlərinə uyğun düzgün platforma seçmələri üçün vacibdir.
Növbəti mərhələ istehsala yerləşdirmədir və bu, orkestrləşdirmə alətləri və konteynerlərdən istifadə etməklə tam avtomatlaşdırılmalıdır. DevOps-un bütün mərhələlərində (istehsal simulyatoru, QA mühiti və faktiki istehsal mühiti) virtuallaşdırılmış mühitlərə malik olmaq və müvafiq nəticələr əldə etmək üçün həmişə testlər üçün yalnız ən son məlumatlardan istifadə etmək vacibdir. Analitika ağıllı olmalı və sürətli və təsirli rəylə böyük məlumatları emal edə bilməlidir.”
3. Günahı məsuliyyətdən götürün.
Gordon Haff, RedHat Evangelist: “Təcrübələrə imkan verən və təşviq edən bir sistem və atmosfer yaratmaq çevik proqram təminatının inkişafında uğurlu uğursuzluqlar kimi tanınan şeylərə imkan verir. Bu o demək deyil ki, uğursuzluqlara görə başqa heç kim məsuliyyət daşımır. Əslində kimin məsuliyyət daşıdığını müəyyən etmək daha da asanlaşır, çünki “məsul olmaq” artıq “qəzaya səbəb olmaq” demək deyil. Yəni məsuliyyətin mahiyyəti keyfiyyətcə dəyişir. Dörd amil kritik hala gəlir: pozulmanın miqyası, yanaşmalar, istehsal prosesləri və stimullar.” (Bu amillər haqqında daha çox Gordon Huffun “DevOps dərsləri: sağlam təcrübələrin 4 aspekti” məqaləsində oxuya bilərsiniz.)
4. İrəli gedən yolu təmizləyin
Ben Grinnell, North Highland konsaltinq şirkətinin idarəedici direktoru və rəqəmsal rəhbəri: “Ölçəyə nail olmaq üçün qabaqcıl layihələrlə birlikdə “yolların təmizlənməsi” proqramını işə salmağı tövsiyə edirəm. Bu proqramın məqsədi DevOps qabaqcıllarının köhnəlmiş qaydalar və bu kimi şeylər kimi geridə qoyduğu zibilləri təmizləməkdir ki, irəliyə doğru yol aydın olsun”.
“Yeni iş üsullarının uğurlarını geniş şəkildə qeyd etməklə, qabaqcıl qrupdan kənara çıxan ünsiyyət vasitəsilə insanlara təşkilati dəstək və sürət verin. DevOps layihələrinin növbəti dalğasında iştirak edən və DevOps-dan ilk dəfə istifadə etməkdən narahat olan insanları məşq edin. Və unutmayın ki, bu insanlar pionerlərdən çox fərqlidirlər”.
5. Alətləri demokratikləşdirin
Steve Newman, Scalyr-in qurucusu və sədri: “Alətlər insanlardan gizlədilməməlidir və vaxt ayırmaq istəyən hər kəs üçün onları öyrənmək nisbətən asan olmalıdır. Əgər jurnalları sorğulamaq imkanı alətdən istifadə etmək üçün "sertifikatlı" üç nəfərlə məhdudlaşdırılıbsa, çox böyük hesablama mühitiniz olsa belə, problemi həll etmək üçün həmişə maksimum üç nəfər olacaq. Yəni burada ciddi (işgüzar) nəticələrə gətirib çıxara biləcək darboğaz var”.
6. Komanda işi üçün ideal şərait yaradın
Tom Klark, İTV-nin Ümumi Platformasının rəhbəri: “Hər şeyi edə bilərsən, amma hər şeyi bir anda deyil. Beləliklə, böyük hədəflər qoyun, kiçik başlayın və sürətli təkrarlarla irəliləyin. Vaxt keçdikcə işləri görmək üçün bir reputasiya qazanacaqsınız, buna görə də başqaları sizin metodlarınızdan istifadə etmək istəyəcəklər. Və yüksək effektiv komanda qurmaqdan narahat olmayın. Bunun əvəzinə insanları ideal iş şəraiti ilə təmin edin və bundan sonra da səmərəlilik olacaq”.
7. Conway Qanunu və Kanban lövhələri haqqında unutmayın
Logan Daigle, CollabNetVersionOne proqram təminatının çatdırılması və DevOps strategiyasının direktoru: “Conway Qanununun nəticələrini başa düşmək vacibdir. Mənim açıq ifadəmlə bu qanun bildirir ki, yaratdığımız məhsullar və bunun üçün istifadə etdiyimiz proseslər, o cümlədən DevOps, təşkilatımızla eyni şəkildə qurulmuşdur.
“Bir təşkilatda çoxlu silos varsa və proqram təminatı planlaşdırarkən, qurarkən və buraxarkən nəzarət dəfələrlə əl dəyişdirirsə, miqyaslaşdırmanın təsiri sıfır və ya qısamüddətli olacaqdır. Təşkilat bazar diqqəti ilə maliyyələşdirilən məhsullar ətrafında funksiyalararası komandalar qurursa, uğur şansı kəskin şəkildə artır.”
“Ölçəkləşdirmənin digər vacib aspekti Kanban lövhələrində davam edən bütün işləri (WIP, workinprogress) göstərməkdir. Bir təşkilat insanların bunları görə biləcəyi bir yerə sahib olduqda, bu, əməkdaşlığı çox təşviq edir və bu, miqyasına müsbət təsir göstərir.
8. Köhnə çapıqları axtarın
Manuel Pais, DevOps məsləhətçisi və Team Topologies-in həmmüəllifi: “DevOps təcrübələrini Dev və Ops-un özündən kənara çıxarmaq və onları digər funksiyalara tətbiq etməyə çalışmaq çətin ki, optimal yanaşmadır. Bu, əlbəttə ki, müəyyən təsir göstərəcək (məsələn, əl ilə idarəetmənin avtomatlaşdırılması yolu ilə), lakin çatdırılma və əks əlaqə proseslərini başa düşməkdən başlasaq, daha çox şey əldə etmək olar.
“Əgər təşkilatın İT sistemində köhnə yaralar varsa - keçmiş hadisələr nəticəsində həyata keçirilmiş, lakin aktuallığını itirmiş prosedurlar və idarəetmə mexanizmləri (məhsullar, texnologiyalar və ya proseslərdəki dəyişikliklərə görə) - o zaman onlar mütləq aradan qaldırılmalıdır. və ya səmərəsiz və ya lazımsız prosesləri avtomatlaşdırmaqdansa, hamarlanmışdır”.
9. DevOps seçimlərini artırmayın
Entoni Edvards, Eggplant-ın Əməliyyatlar Direktoru: “DevOps çox qeyri-müəyyən bir termindir, ona görə də hər komanda öz DevOps versiyası ilə başa çatır. Bir təşkilatda birdən-birə 20 növ DevOps olduqda, daha pis bir şey yoxdur ki, onlar bir-biri ilə yaxşı yola getmirlər. Üç inkişaf qrupunun hər birinin inkişaf və məhsulun idarə edilməsi arasında özünəməxsus, xüsusi interfeysi olması mümkün deyil. Məhsulların istehsal simulyatoruna köçürüldükdə əks əlaqə ilə bağlı özünəməxsus gözləntiləri də olmamalıdır. Əks halda, siz heç vaxt DevOps-u genişləndirə bilməyəcəksiniz.”
10. DevOps-un biznes dəyərini təbliğ edin
Steve Newman, Scalyr-in qurucusu və sədri: “DevOps-un dəyərini tanımağa çalışın. Öyrənin və etdiyiniz işin faydaları haqqında danışmaqdan çekinmeyin. DevOps inanılmaz vaxta və pula qənaət edir (sadəcə düşünün: daha az dayanma vaxtı, bərpa üçün daha qısa vaxt) və DevOps komandaları yorulmadan biznes uğuru üçün bu təşəbbüslərin əhəmiyyətini vurğulamalıdır (və təbliğ etməlidir). Bu yolla siz tərəfdarların dairəsini genişləndirə və DevOps-un təşkilatdakı təsirini artıra bilərsiniz.”
BONUS
Haqqında Öz DevOps-larımız sentyabrın 13-də gələcək - bəli, Red Hat proqram istehsalçısı olaraq öz DevOps komandaları və təcrübələrinə malikdir.
Təşkilat daxilində digər qruplar üçün daxili avtomatlaşdırma xidmətlərini inkişaf etdirən mühəndisimiz Mark Birger öz hekayəsini sırf rus dilində danışacaq - Red Hat DevOps komandası Ansible tərəfindən idarə olunan Hat Virtualization virtual mühitlərindən proqramları tam hüquqlu konteyner formatına necə köçürdü? OpenShift platforması.
Ancaq bu hamısı deyil:
Təşkilatlar iş yüklərini konteynerlərə köçürdükdən sonra ənənəvi tətbiq monitorinq üsulları işləməyə bilər. İkinci çıxışda biz giriş üsulumuzu dəyişdirmək üçün motivasiyamızı izah edəcəyik və bizi müasir giriş və monitorinq üsullarına aparan yolun davamını göstərəcəyik.
Mənbə: www.habr.com