"Devopları necə həyata keçirmək olar" sualı illərdir mövcuddur, lakin yaxşı materiallar çox deyil. Bəzən necə olursa olsun, vaxtını satmağa ehtiyacı olan çox da ağıllı olmayan məsləhətçilərin reklamlarının qurbanı olursunuz. Bəzən bunlar meqakorporasiyaların gəmilərinin kainatın genişliklərini necə şumladığı haqqında qeyri-müəyyən, son dərəcə ümumi sözlərdir. Sual yaranır: bunun bizə nə dəxli var? Hörmətli müəllif, fikirlərinizi siyahıda aydın şəkildə ifadə edə bilərsinizmi?
Bütün bunlar ondan irəli gəlir ki, şirkət mədəniyyətinin çevrilməsinin nəticələrinə dair çox real təcrübə və anlayış yığılmayıb. Mədəniyyətdəki dəyişikliklər uzunmüddətli şeylərdir, nəticələri bir həftə və ya bir ay ərzində görünməyəcəkdir. Bizə şirkətlərin illər ərzində necə qurulduğunu və uğursuzluğa düçar olduğunu görəcək qədər yaşlı biri lazımdır.
Con Uillis - DevOps-un atalarından biri. Conun çoxlu sayda şirkətlə işləmək təcrübəsi var. Bu yaxınlarda John onların hər biri ilə işləyərkən baş verən xüsusi nümunələri görməyə başladı. Bu arxetiplərdən istifadə edən Con şirkətləri DevOps transformasiyasının əsl yoluna yönəldir. Bu arxetiplər haqqında onun DevOops 2018 konfransındakı hesabatının tərcüməsində oxuyun.
Natiq haqqında:
İT menecmentində 35 ildən artıqdır ki, Canonical-da OpenCloud-un sələfinin yaradılmasında iştirak edib, 10 startapda iştirak edib, onlardan ikisi Dell və Docker-ə satılıb. Hal-hazırda o, SJ Technologies-də DevOps və Rəqəmsal Təcrübələr üzrə vitse-prezidentdir.
Sonrakı hekayə Conun nöqteyi-nəzərindəndir.
Mənim adım John Willis və məni tapmaq üçün ən asan yer Twitter-də, . Gmail və GitHub-da eyni ləqəbim var. A hesabatlarımın video yazılarını və onlar üçün təqdimatları tapa bilərsiniz.
Müxtəlif iri şirkətlərin CIO-ları ilə çoxlu görüşlərim olur. Çox vaxt DevOps-un nə olduğunu başa düşmədiklərindən şikayətlənirlər və bunu onlara izah etməyə çalışan hər kəs fərqli bir şey haqqında danışır. Başqa bir ümumi şikayət, DevOps-un işləməməsidir, baxmayaraq ki, direktorlar hər şeyi onlara izah edildiyi kimi edirlər. Söhbət yaşı yüz ildən çox olan böyük şirkətlərdən gedir. Onlarla söhbət etdikdən sonra belə qənaətə gəldim ki, bir çox problemlər üçün ən uyğun olan yüksək texnologiya deyil, nisbətən aşağı texnoloji həllərdir. Həftələrlə sadəcə müxtəlif şöbələrdən olan insanlarla danışdım. Yazıdakı ilk şəkildə gördüyünüz mənim son layihəmdir, otaq üç günlük işdən sonra belə görünürdü.
DevOps nədir?
Doğrudan da, 10 fərqli insandan soruşsanız, 10 fərqli cavab verəcəklər. Ancaq maraqlısı budur: bu on cavabın hamısı düzgün olacaq. Burada səhv cavab yoxdur. Mən təxminən 10 il ərzində DevOps-a olduqca dərindən daxil olmuşam və ilk DevOpsDay-da ilk amerikalı olmuşam. Mən DevOps-da iştirak edən hər kəsdən daha ağıllı olduğumu söyləməyəcəyəm, lakin buna çox səy sərf edən demək olar ki, yoxdur. İnanıram ki, DevOps insan kapitalı və texnologiya bir araya gəldikdə baş verir. Biz çox vaxt insan ölçüsünü unuduruq, baxmayaraq ki, bütün mədəniyyətlər haqqında çox danışırıq.
İndi bizdə çoxlu məlumatlar, beş illik akademik tədqiqatlar, sənaye miqyasında nəzəriyyələrin sınaqdan keçirilməsi var. Bu tədqiqatların bizə dediyi budur ki, təşkilat mədəniyyətində bəzi davranış nümunələrini birləşdirsəniz, 2000x sürətə nail ola bilərsiniz. Bu sürətlənmə sabitliyin eyni dərəcədə yaxşılaşması ilə üst-üstə düşür. Bu, DevOps-un istənilən şirkətə gətirə biləcəyi faydanın kəmiyyət ölçüsüdür. Bir neçə il əvvəl mən bir Fortune 5000 şirkətinin baş direktoruna DevOps haqqında danışırdım.Təqdimata hazırlaşarkən çox əsəbi idim, çünki illərin təcrübəmi 5 dəqiqəyə ümumiləşdirməli idim.
Sonda aşağıdakıları verdim DevOps-un tərifi: Bu, insan kapitalının yüksək effektiv təşkilat kapitalına çevrilməsinə imkan verən təcrübələr və nümunələr toplusudur. Buna misal olaraq Toyota-nın son 50 və ya 60 ildə necə işlədiyini göstərmək olar.
(Bundan sonra belə diaqramlar istinad materialı kimi deyil, illüstrasiya kimi təqdim olunur. Onların məzmunu hər bir yeni şirkət üçün fərqli olacaq. Bununla belə, şəkilə ayrıca baxmaq və böyütmək olar.
Ən uğurlu bu cür təcrübələrdən biridir dəyəri stream mapping. Bu barədə bir neçə yaxşı kitab yazılmışdır, onlardan ən uğurlusu Karen Martindir. Ancaq son bir ildə mən belə qənaətə gəldim ki, hətta bu yanaşma çox yüksək texnologiyalıdır. Bunun əlbəttə ki, bir çox üstünlükləri var və mən ondan çox istifadə etmişəm. Lakin CEO sizdən şirkətinin niyə yeni relslərə keçə bilmədiyini soruşduqda, dəyər axınının xəritələşdirilməsi haqqında danışmaq hələ tezdir. Əvvəlcə cavablandırılmalı olan daha çox əsas suallar var.
Düşünürəm ki, bir çox həmkarlarımın etdiyi səhv şirkətə sadəcə beş bəndlik bələdçi vermək və altı aydan sonra geri qayıdıb nə baş verdiyini görməkdir. Hətta dəyər axınının xəritələşdirilməsi kimi yaxşı bir sxem, deyək ki, kor nöqtələrə malikdir. Müxtəlif şirkətlərin direktorları ilə yüzlərlə müsahibədən sonra mən problemi onun komponentlərinə ayırmağa imkan verən müəyyən bir nümunə hazırladım və indi bu komponentlərin hər birini ardıcıllıqla müzakirə edəcəyik. Hər hansı texnoloji həllər tətbiq etməzdən əvvəl mən bu nümunədən istifadə edirəm və nəticədə bütün divarlarım diaqramlarla örtülmüşdür. Bu yaxınlarda mən pay fondu ilə işləyirdim və 100-150 belə sxemlə başa çatdım.
Pis mədəniyyət səhər yeməyi üçün yaxşı yanaşmalar yeyir
Əsas fikir budur: təşkilatın mədəniyyəti pis olarsa, heç bir miqdar Lean, Agile, SAFE və DevOps kömək etməyəcək. Bu, skuba alətləri olmadan dərinliklərə dalmağa və ya rentgensiz işləməyə bənzəyir. Başqa sözlə, Drucker və Deming desək: pis təşkilat mədəniyyəti istənilən yaxşı sistemi boğmadan udacaq.
Bu əsas problemi həll etmək üçün aşağıdakı addımları atmalısınız:
- Bütün işləri görünən edin: bütün işləri görünən etmək lazımdır. O mənada deyil ki, o, mütləq hansısa ekranda göstərilməlidir, lakin müşahidə oluna bilən olmalıdır.
- Konsolidasiya edilmiş İş İdarəetmə Sistemləri: idarəetmə sistemləri konsolidasiya edilməlidir. “Təbiət” biliyi və institusional bilik problemində hər 9 hadisədən 10-da darboğaz insanlardır. Kitabda problem layihənin üç il gecikdirilməsinə səbəb olan tək bir şəxslə, Brentlə bağlı idi. Mən hər yerdə bu "Brents"lə qarşılaşıram. Bu darboğazları həll etmək üçün siyahımızda növbəti iki maddədən istifadə edirəm.
- Məhdudiyyətlər nəzəriyyəsi metodologiyası: məhdudiyyətlər nəzəriyyəsi.
- Əməkdaşlıq hiylələri: əməkdaşlıq hackləri.
- Toyota Kata (): Toyota Kata haqqında çox danışmayacağam. Maraqlıdırsa, mənim github-da bu mövzuların demək olar ki, hər birində.
- Bazar yönümlü təşkilat: bazar yönümlü təşkilat.
- Növbəli sola auditorlar: dövrün erkən mərhələlərində audit.
Mən çox sadə bir təşkilatla işə başlayıram: şirkətə gedirəm və işçilərlə danışıram. Gördüyünüz kimi, yüksək texnologiya yoxdur. Sizə yalnız yazmaq üçün bir şey lazımdır. Mən bir otaqda bir neçə komanda toplayıram və onların mənə dediklərini mənim 7 arxetipimin prizmasından təhlil edirəm. Sonra mən onlara bir marker verirəm və indiyə qədər ucadan söylədiklərinin hamısını lövhəyə yazmağı xahiş edirəm. Adətən bu tip görüşlərdə bir nəfər olur ki, hər şeyi yazır və ən yaxşı halda müzakirənin 10%-ni yaza bilir. Mənim metodumla bu rəqəmi təxminən 40%-ə çatdırmaq olar.
(Bu illüstrasiya ayrıca baxıla bilər )
Mənim yanaşmam Uilyam Şnayderin işinə əsaslanır. ). Bu yanaşma hər hansı bir təşkilatın dörd kvadrata bölünə biləcəyi fikrinə əsaslanır. Mənim üçün bu sxem adətən bir təşkilatı təhlil edərkən ortaya çıxan yüzlərlə digər sxemlərlə işləməyin nəticəsidir. Tutaq ki, bizdə nəzarəti yüksək, lakin səriştəsi aşağı olan bir təşkilat var. Bu, son dərəcə arzuolunmaz bir seçimdir: hamı xəttin barmağında olduqda, lakin heç kim nə edəcəyini bilmir.
Bir qədər daha yaxşı seçim həm nəzarət, həm də səriştə səviyyəsi yüksək olan seçimdir. Əgər belə bir şirkət gəlirlidirsə, bəlkə də DevOps-a ehtiyac yoxdur. Nəzarət səviyyəsi yüksək, səriştəsi və əməkdaşlığı aşağı, eyni zamanda mədəniyyəti (becərilməsi) yüksək olan şirkətlə işləmək ən maraqlıdır. Bu o deməkdir ki, şirkətdə işləməyi sevənlər çoxdur və işçi qüvvəsi aşağıdır.
(Bu illüstrasiya ayrıca baxıla bilər )
Mənə elə gəlir ki, sərt təlimatları olan üsullar həqiqətə çatmaq yolunda əngəl törədir. Xüsusilə dəyər axınının xəritələşdirilməsində məlumatın necə strukturlaşdırılması ilə bağlı bir çox qaydalar var. İndi haqqında danışdığım işin ilkin mərhələlərində bu qaydalar heç kimə lazım deyil. Əlində marker olan bir şəxs lövhədə şirkətdəki real vəziyyəti təsvir edirsə, bu, işin vəziyyətini başa düşməyin ən yaxşı yoludur. Belə məlumatlar direktorlara çatmır. Bu məqamda adamın sözünü kəsib hansısa ox yanlış çəkdiyini söyləmək axmaqlıqdır. Bu mərhələdə sadə qaydalardan istifadə etmək daha yaxşıdır, məsələn: çoxsəviyyəli abstraksiya sadəcə çox rəngli markerlərdən istifadə etməklə yaradıla bilər.
Yenə deyirəm, yüksək texnologiya yoxdur. Qara marker hər şeyin necə işlədiyinin obyektiv reallığını təsvir edir. Qırmızı markerlə insanlar mövcud vəziyyətlə bağlı bəyənmədiklərini qeyd edirlər. Bunu mənim yox, onların yazması vacibdir. Mən görüşdən sonra CIO-ya gedəndə düzəldilməli olan 10 şeyin siyahısını təklif etmirəm. Mən şirkətdəki insanların dedikləri ilə mövcud sübut edilmiş nümunələr arasında əlaqə tapmağa çalışıram. Nəhayət, mavi marker problemin mümkün həll yollarını təklif edir.
(Bu illüstrasiya ayrıca baxıla bilər )
Bu yanaşmanın bir nümunəsi indi yuxarıda təsvir edilmişdir. Bu ilin əvvəlində bir bankla işləmişəm. Oradakı təhlükəsizlik işçiləri əmin idilər ki, dizayn və tələblərin nəzərdən keçirilməsinə gəlməməlidirlər.
(Bu illüstrasiya ayrıca baxıla bilər )
Və sonra biz digər şöbələrdən olan insanlarla danışdıq və məlum oldu ki, təxminən 8 il əvvəl proqram tərtibatçıları işini ləngitdikləri üçün təhlükəsizlik işçilərini işdən çıxarıblar. Və sonra bu, təbii qəbul edilən qadağaya çevrildi. Baxmayaraq ki, əslində heç bir qadağa yox idi.
Görüşümüz son dərəcə çaşqın şəkildə keçdi: təxminən üç saat ərzində beş müxtəlif komanda kodla məclis arasında nə baş verdiyini mənə izah edə bilmədi. Və bu ən sadə şey kimi görünür. Əksər DevOps məsləhətçiləri əvvəlcədən hər kəsin bunu bildiyini düşünürlər.
Sonra dörd saat susmuş İT idarəçiliyinə cavabdeh olan şəxs onun mövzusuna çatanda birdən-birə canlandı və bizi çox uzun müddət məşğul etdi. Sonda ondan görüş haqqında nə düşündüyünü soruşdum və cavabını heç vaxt unutmayacağam. O dedi: "Əvvəllər bankımızın proqram təminatının yalnız iki yolu olduğunu düşünürdüm, amma indi bilirəm ki, onlardan beşi var və üçü haqqında heç xəbərim də yox idi."
(Bu illüstrasiya ayrıca baxıla bilər )
Bu bankda son görüş investisiya proqramı komandası ilə oldu. Onunla bir vərəqdə markerlə diaqramların yazılması lövhədən, hətta smartboarddan daha yaxşı olduğu ortaya çıxdı.
Gördüyünüz fotolar görüşümüzün dördüncü günündə otelin konfrans zalının necə göründüyüdür. Və biz bu sxemlərdən nümunələri, yəni arxetipləri axtarmaq üçün istifadə etdik.
Beləliklə, işçilərə suallar verirəm, cavabları üç rəngli (qara, qırmızı və mavi) markerlərlə yazırlar. Mən onların cavablarını arxetiplər üçün təhlil edirəm. İndi bütün arxetipləri ardıcıllıqla müzakirə edək.
1. Bütün işləri görünən edin: işi görünən edin
İşlədiyim şirkətlərin əksəriyyətində naməlum işlərin çox yüksək faizi var. Məsələn, bu, bir işçinin digərinə gəldiyi və sadəcə bir şey etməyi xahiş etdiyi zamandır. Böyük təşkilatlarda 60% plansız iş ola bilər. Və işin 40%-ə qədəri heç bir şəkildə sənədləşdirilmir. Boeing olsaydı, mən həyatımda bir daha onların təyyarəsinə minməzdim. Əgər işin yalnız yarısı sənədləşdirilibsə, o zaman bu işin düzgün aparılıb-yapılmaması məlum deyil. Bütün digər üsullar faydasız olur - heç bir şeyi avtomatlaşdırmağa çalışmağın mənası yoxdur, çünki məlum 50% işin ən ardıcıl və aydın hissəsi ola bilər, avtomatlaşdırılması böyük nəticələr verməyəcək və ən pisi şeylər görünməz yarıdadır. Sənədləşmə olmadıqda, hər cür hack və gizli işi tapmaq mümkün deyil, darboğazları, artıq danışdığım "Brents" ləri tapmaq deyil. Dominika DeQrandisin gözəl bir kitabı var . O ifşa edir beş fərqli "zaman sızması" (zaman oğruları):
- Prosesdə Həddindən artıq İş (WIP)
- Naməlum Asılılıqlar
- Plansız iş
- Ziddiyyətli prioritetlər
- Baxımsız İş
Bu çox dəyərli təhlildir və kitab əladır, lakin məlumatların yalnız 50%-i görünsə, bütün bu məsləhətlər faydasızdır. Dominika tərəfindən təklif olunan üsullar 90%-dən yuxarı dəqiqliyə nail olunarsa istifadə edilə bilər. Müdirin tabeçiliyinə 15 dəqiqəlik tapşırıq verdiyi vəziyyətlərdən danışıram, lakin bu, ona üç gün çəkir; amma rəis doğrudan da bilmir ki, bu tabeliyində olan adam dörd-beş başqa adamdan asılıdır.
Phoenix Layihəsi üç il çox gecikmiş bir layihə haqqında gözəl bir hekayədir. Personajlardan biri bu səbəbdən işdən çıxarılma ilə üzləşir və o, bir növ Sokrat kimi təqdim olunan başqa bir personajla qarşılaşır. Tam olaraq nəyin səhv olduğunu anlamağa kömək edir. Belə çıxır ki, şirkətin bir sistem administratoru var, adı Brent və bütün işlər birtəhər onun vasitəsilə keçir. İclasların birində tabeliyində olanlardan birinə sual verilir: niyə hər yarım saatlıq iş bir həftə çəkir? Cavab növbə nəzəriyyəsinin və Little qanununun çox sadələşdirilmiş təqdimatıdır və bu təqdimatda məlum olur ki, 90% doluluqda hər iş saatı 9 saat çəkir. Hər tapşırığı yeddi başqa adama göndərmək lazımdır, belə ki, bu saat 63 saat olur, 7 dəfə 9. Demək istədiyim odur ki, Kiçik Qanundan və ya hər hansı mürəkkəb növbə nəzəriyyəsindən istifadə etmək üçün ən azı məlumatınız olmalıdır.
Beləliklə, mən görünürlük haqqında danışarkən, hər şeyin ekranda olduğunu deyil, ən azı məlumatların olduğunu nəzərdə tuturam. Bunu edəndə çox vaxt məlum olur ki, çox böyük miqdarda planlaşdırılmamış iş var ki, ehtiyac olmadığı halda hansısa yolla Brent-ə göndərilir. Brent isə əla oğlandır, heç vaxt yox deməyəcək, amma işini necə yerinə yetirdiyini heç kimə demir.
İş göründükdə, məlumatlar səliqəli şəkildə təsnif edilə bilər (fotoda Dominika bunu edir), beş vaxt sızmasının abstraksiyasını tətbiq etmək və avtomatlaşdırma tətbiq etmək olar.
2. İşin İdarə Edilməsi Sistemlərini birləşdirin: Tapşırıqların İdarə Edilməsi
Haqqında danışdığım arxetiplər bir növ piramidadır. Birincisi düzgün aparılırsa, ikincisi artıq bir növ əlavədir. Bunların bir çoxu startaplar üçün işləmir, onları Fortune 5000 kimi daha böyük şirkətlər üçün yadda saxlamaq lazımdır. Son işlədiyim şirkətdə 10 bilet sistemi var idi. Bir komandada Remedy var idi, digəri bir növ öz sistemini yazdı, üçüncüsü Jiradan istifadə etdi və bəziləri e-poçtla məşğul oldu. Şirkətin 30 müxtəlif boru kəməri varsa, eyni problem yaranır, amma bütün belə halları müzakirə etməyə vaxtım yoxdur.
Mən insanlarla biletlərin necə yaradıldığını, bundan sonra onlara nə baş verdiyini və onlardan necə yayınıldığını müzakirə edirəm. Ən maraqlısı odur ki, bizim görüşlərdə insanlar kifayət qədər səmimi danışırlar. Mən soruşdum ki, nə qədər insan biletlərə "kiçik / təsirsiz" qoyur, əslində "böyük təsir" verilməlidir. Məlum oldu ki, bunu demək olar ki, hamı edir. Mən qınama ilə məşğul olmuram və insanları müəyyən etməmək üçün hər cür cəhd edirəm. Mənə səmimiyyətlə bir şey etiraf edəndə, mən o adamı əlimdən almıram. Ancaq demək olar ki, hər kəs sistemdən yan keçdikdə, bu, bütün təhlükəsizliyin mahiyyətcə pəncərə sarğı olduğunu göstərir. Buna görə də bu sistemin məlumatlarından heç bir nəticə çıxarmaq olmaz.
Bilet problemini həll etmək üçün bir əsas sistem seçmək lazımdır. Jira istifadə edirsinizsə, onu Jira saxlayın. Əgər hər hansı bir alternativ varsa, qoy yeganə olsun. Nəticə odur ki, biletlərə inkişaf prosesində başqa bir addım kimi baxmaq lazımdır. Hər bir hərəkətin bir bileti olmalıdır və bu, inkişaf iş axınından keçməlidir. Biletlər komandaya göndərilir, o, onları hekayə lövhəsində yerləşdirir və sonra onlar üçün məsuliyyət daşıyır.
Bu, infrastruktur və əməliyyatlar da daxil olmaqla bütün departamentlərə aiddir. Bu halda, heç olmasa, vəziyyətlə bağlı bəzi inandırıcı fikir formalaşdırmaq olar. Bu proses qurulduqdan sonra hər bir müraciət üçün kimin məsuliyyət daşıdığını müəyyən etmək birdən-birə asanlaşır. Çünki indi biz yeni xidmətlərin 50 faizini deyil, 98 faizini alırıq. Bu əsas proses işləyirsə, sistem boyu dəqiqlik yaxşılaşır.
Xidmət boru kəməri
Bu yenə də yalnız böyük korporasiyalara aiddir. Əgər siz yeni bir sahədə yeni şirkətsinizsə, qollarınızı yuxarı çəkin və Travis CI və ya CircleCI ilə işləyin. Fortune 5000 şirkətlərinə gəldikdə, işlədiyim bankda baş verən bir hadisə. Google onların yanına gəldi və onlara köhnə IBM sistemlərinin diaqramları göstərildi. Google-dan olan uşaqlar çaşqınlıqla soruşdular - bunun üçün mənbə kodu haradadır? Ancaq mənbə kodu, hətta GUI də yoxdur. Bu, böyük təşkilatların qarşılaşmalı olduğu reallıqdır: qədim meynfreymdə 40 illik bank qeydləri. Müştərilərimdən biri KeyBank tətbiqi üçün Circuit Breaker naxışlı Kubernetes konteynerlərindən, üstəgəl Chaos Monkey-dən istifadə edir. Lakin bu konteynerlər son nəticədə COBOL tətbiqinə qoşulur.
Google-dan olan uşaqlar müştərimin bütün problemlərini həll edəcəklərinə tam əmin idilər və sonra suallar verməyə başladılar: IBM datapipe nədir? Onlara deyilir: bu bağlayıcıdır. Bu nə ilə bağlıdır? Sperry sisteminə. Bəs bu nədir? Və s. İlk baxışdan belə görünür: hansı DevOps ola bilər? Amma əslində bu mümkündür. İş axınını çatdırılma qruplarına təhvil verməyə imkan verən çatdırılma sistemləri var.
3. Məhdudiyyətlər nəzəriyyəsi: Məhdudiyyətlər nəzəriyyəsi
Gəlin üçüncü arxetipə keçək: institusional/"tayfa" bilikləri. Bir qayda olaraq, hər hansı bir təşkilatda hər şeyi bilən və hər şeyi idarə edən bir neçə adam olur. Bunlar təşkilatda ən uzun müddət olan və bütün həll yollarını bilənlərdir.
Bu, diaqramda ortaya çıxanda, mən xüsusi olaraq belə insanları markerlə əhatə edirəm: məsələn, məlum olur ki, bütün görüşlərdə müəyyən bir Lou iştirak edir. Və mənə aydındır: bu, yerli Brentdir. CIO mənim köynək və idman ayaqqabısı ilə IBM-dən kostyumlu oğlan arasında seçim etdikdə, mən seçilirəm, çünki rejissora başqasının deməyəcəyi və rejissorun eşitmək istəməyə biləcəyi şeyləri deyə bilirəm. . Mən onlara deyirəm ki, şirkətlərində darboğaz Fred və Lou adlı birisidir. Bu darboğazı açmaq lazımdır, onların biliklərini bu və ya digər şəkildə onlardan almaq lazımdır.
Bu cür problemi həll etmək üçün, məsələn, Slack istifadə etməyi təklif edə bilərəm. Ağıllı direktor soruşacaq - niyə? Tipik olaraq, belə hallarda DevOps məsləhətçiləri cavab verir: çünki hamı bunu edir. Direktor doğrudan da ağıllıdırsa, deyəcək: bəs nə. Və bu, dialoqun bitdiyi yerdir. Buna cavabım belədir: çünki şirkətdə dörd darboğaz var, Fred, Lou, Susie və Jane. Biliklərini institusionallaşdırmaq üçün əvvəlcə Slack tətbiq edilməlidir. Sizin bütün vikiləriniz tamamilə cəfəngiyatdır, çünki onların varlığından heç kimin xəbəri yoxdur. Mühəndislik qrupu front-end və back-end inkişafında iştirak edirsə və hər kəs suallarla front-end inkişaf komandası və ya infrastruktur komandası ilə əlaqə saxlaya biləcəyini bilməlidir. O zaman Lou və ya Fredin vikiyə qoşulmağa vaxtı olacaq. Sonra Slack-də kimsə soruşa bilər ki, niyə 5-ci addım işləmir. Sonra Lou və ya Fred vikidəki təlimatları düzəldəcək. Bu prosesi qursanız, çox şey öz-özünə yerinə düşəcək.
Bu mənim əsas fikrimdir: hər hansı yüksək texnologiyaları tövsiyə etmək üçün əvvəlcə onların təməlini qaydaya salmalısınız və bu, yuxarıda təsvir olunan aşağı texnologiyalı həllər ilə edilə bilər. Əgər siz yüksək texnologiyalardan başlasanız və onların nə üçün lazım olduğunu izah etmirsinizsə, bir qayda olaraq, bunun sonu yaxşı bitmir. Müştərilərimizdən biri çox ucuz və sadə həll yolu olan Azure ML-dən istifadə edir. Onların suallarının təxminən 30%-nə özünü öyrənən maşının özü cavab verib. Və bu şey məlumat elmi, statistika və ya riyaziyyatla məşğul olmayan operatorlar tərəfindən yazılmışdır. Bu əlamətdardır. Belə bir həllin dəyəri minimaldır.
4. Əməkdaşlıq hackləri: Əməkdaşlıq hackləri
Dördüncü arxetip təcridlə mübarizə ehtiyacıdır. Əksər insanlar bunu artıq bilirlər: təcrid düşmənçilik yaradır. Əgər hər bir şöbə öz mərtəbəsindədirsə və insanlar liftdən başqa heç bir şəkildə bir-biri ilə kəsişmirsə, o zaman aralarında düşmənçilik çox asanlıqla yaranır. Ancaq əksinə, insanlar bir-biri ilə eyni otaqdadırsa, dərhal ayrılır. Kimsə ümumi ittihamı atanda, məsələn, filan interfeys heç vaxt işləmir, belə bir ittihamı dekonstruksiya etməkdən asan bir şey yoxdur. İnterfeys yazan proqramçılar sadəcə olaraq konkret suallar verməyə başlamalıdırlar və tezliklə məlum olacaq ki, məsələn, istifadəçi sadəcə olaraq alətdən səhv istifadə edib.
İzolyasiyanı aradan qaldırmağın bir çox yolu var. Bir dəfə məndən Avstraliyada bir bankla məsləhətləşmək istədilər, amma iki uşağım və həyat yoldaşım olduğu üçün bunu etməkdən imtina etdim. Onlara kömək etmək üçün edə biləcəyim yeganə şey qrafik hekayəni tövsiyə etmək idi. Bu işlədiyi sübut edilmiş bir şeydir. Başqa bir maraqlı yol arıq qəhvə görüşləridir. Böyük bir təşkilatda bu, biliklərin yayılması üçün əla seçimdir. Bundan əlavə, siz daxili devopsdays, hackathons və s. keçirə bilərsiniz.
5. Kata məşqçiliyi
Əvvəldən xəbərdarlıq etdiyim kimi, bu gün bu barədə danışmayacağam. Əgər maraqlanırsınızsa, baxa bilərsiniz .
Bu mövzuda Mike Rother-dən yaxşı bir söhbət də var:
6. Bazar yönümlü: bazar yönümlü təşkilat
Burada müxtəlif problemlər var. Məsələn, "I" insanlar, "T" insanlar və "E" insanlar. "Mən" insanlar yalnız bir şey edənlərdir. Adətən onlar təcrid olunmuş şöbələri olan təşkilatlarda mövcuddur. "T" insanın bir şeydə yaxşı olduğu halda, bəzi başqa şeylərdə də yaxşı olmasıdır. "E" və ya hətta "daraq" bir insanın bir çox bacarığı olan zamandır.
Konvey qanunu burada işləyir (), ən sadələşdirilmiş formada belə ifadə edilə bilər: tərtibçi üzərində üç komanda işləyirsə, nəticə üç hissədən ibarət tərtibçi olacaqdır. Buna görə, bir təşkilat daxilində yüksək səviyyədə təcrid varsa, bu təşkilatda hətta Kubernetes, Circuit breaker, API genişlənməsi və digər zərif şeylər təşkilatın özü ilə eyni şəkildə təşkil ediləcəkdir. Ciddi Conway görə və bütün gənc geeks nifrət etmək.
Bu problemin həlli dəfələrlə təsvir edilmişdir. Məsələn, Fernando Fernandes tərəfindən təsvir edilən təşkilati arxetiplər var. Haqqında danışdığım problemli arxitektura, təcrid olunmaqla, funksiya yönümlü bir arxitekturadır. İkinci növ ən pis, matris arxitekturası, digər ikisinin qarışıqlığıdır. Üçüncüsü, əksər startaplarda müşahidə olunan şeydir və böyük şirkətlər də bu tipə uyğun gəlməyə çalışırlar. Bu, bazar yönümlü bir təşkilatdır. Müştəri sorğularına ən sürətli cavab vermək üçün burada optimallaşdırırıq. Buna bəzən düz təşkilat da deyirlər.
Bir çox insan bu quruluşu müxtəlif cür təsvir edir, ifadəni bəyənirəm komandalar qurmaq/çalışdırmaq, Amazonda bunu adlandırırlar iki pizza komandası. Bu strukturda bütün “I” tipli insanlar bir xidmət ətrafında qruplaşdırılır və getdikcə “T” tipinə yaxınlaşırlar və düzgün idarəçilik olarsa, hətta “E”yə çevrilə bilirlər. Burada ilk əks arqument belə bir strukturun lazımsız elementlərə malik olmasıdır. Testerlərin xüsusi şöbəsi ola bilərsə, niyə hər bir şöbədə bir testerə ehtiyacınız var? Mən cavab verirəm: bu halda əlavə xərclər bütün təşkilatın gələcəkdə “E” növünə çevrilməsi üçün qiymətdir. Bu strukturda tester tədricən şəbəkələr, memarlıq, dizayn və s. Nəticədə təşkilatın hər bir iştirakçısı təşkilatda baş verən hər şeydən tam xəbərdar olur. Bu sxemin sənayedə necə işlədiyini bilmək istəyirsinizsə, oxuyun .
7. Növbəli sola auditorlar: dövrün əvvəlində audit. Ekranda təhlükəsizlik qaydalarına riayət edilməsi
Bu, hərəkətləriniz, belə deyək, qoxu testindən keçmədiyi zamandır. Sizin üçün işləyən insanlar axmaq deyillər. Əgər yuxarıdakı misalda olduğu kimi, hər yerdə cüzi/heç bir təsir göstərməsələr, bu üç il davam etdi və heç kim heç nə hiss etmədisə, deməli, sistemin işləmədiyini hamı çox yaxşı bilir. Və ya başqa bir nümunə - hesabatların hər, məsələn, çərşənbə günü təqdim edilməli olduğu dəyişikliklər üzrə məsləhət şurası. Orada çalışan bir qrup insan var (yeri gəlmişkən, o qədər də yaxşı maaş almır) onlar nəzəri olaraq bütövlükdə sistemin necə işlədiyini bilməlidirlər. Və son beş il ərzində yəqin ki, sistemlərimizin inanılmaz dərəcədə mürəkkəb olduğunu fərq etmisiniz. Beş-altı nəfər isə etmədikləri və haqqında heç nə bilmədiyi bir dəyişikliklə bağlı qərar verməlidir.
Təbii ki, bu yanaşma işləmir. Mən belə şeylərdən qurtulmalıyam, çünki bu insanlar sistemi qorumurlar. Qərarı komanda özü verməlidir, çünki komanda buna cavabdeh olmalıdır. Əks halda, həyatında heç vaxt kod yazmamış menecer proqramçıya kodu yazmaq üçün nə qədər vaxt lazım olduğunu söylədikdə paradoksal vəziyyət yaranır. İşlədiyim bir şirkətdə memarlıq lövhəsi, məhsul lövhəsi və s. daxil olmaqla, hər dəyişikliyi nəzərdən keçirən 7 fərqli şura var idi. Hətta məcburi gözləmə müddəti də var idi, baxmayaraq ki, bir işçi mənə dedi ki, on il işlədiyi müddətdə heç kim bu məcburi müddət ərzində bu şəxsin etdiyi dəyişikliyi rədd etməyib.
Auditorları bizə qoşulmağa dəvət etmək lazımdır, onlardan qurtulmamaq lazımdır. Onlara deyin ki, siz dəyişməz ikili konteynerlər yazırsınız ki, onlar bütün sınaqlardan keçsələr, əbədi olaraq dəyişməz qalacaqlar. Onlara kod olaraq bir boru kəməriniz olduğunu söyləyin və bunun nə demək olduğunu izah edin. Onlara aşağıdakı sxemi göstərin: bütün zəiflik testlərindən keçən konteynerdəki dəyişməz yalnız oxunuşlu binar; və sonra nəinki heç kim ona toxunmur, hətta boru kəmərini yaradan sistemə də toxunmur, çünki o, həm də dinamik şəkildə yaradılır. Blokçeyn kimi bir şey yaratmaq üçün Vault-dan istifadə edən Capital One müştərilərim var. Auditorun Aşpazdan “reseptləri” göstərməsinə ehtiyac yoxdur, istehsalda Jira biletinə nə baş verdiyini və buna kimin cavabdeh olduğunu aydınlaşdıran blokçeyni göstərmək kifayətdir.
Uyğun olaraq , 2018-ci ildə Sonatype tərəfindən yaradılıb, 2017-ci ildə 87 milyard OSS yükləmə sorğusu olub.
Zəifliklərə görə dəymiş itkilər hədsizdir. Üstəlik, indi yuxarıda gördüyünüz rəqəmlərə fürsət xərcləri daxil deyil. Bir sözlə DevSecOps nədir? Dərhal deyim ki, bu adın nə qədər uğurlu olması haqda danışmaq mənə maraqlı deyil. Məsələ burasındadır ki, DevOps çox uğurlu olduğu üçün biz bu boru kəmərinə təhlükəsizlik əlavə etməyə çalışmalıyıq.
Bu ardıcıllığa bir nümunə:
Bu, xüsusi məhsullar üçün tövsiyə deyil, baxmayaraq ki, hamısını bəyənirəm. Əvvəlcə sənayedəki təşkilati paradiqmaya əsaslanan DevOps-un məhsul üzərində işin hər mərhələsini avtomatlaşdırmağa imkan verdiyini göstərmək üçün bunları misal çəkdim.
Təhlükəsizliyə eyni yanaşmağı qəbul edə bilməməyimiz üçün heç bir səbəb yoxdur.
Ümumi
Nəticə olaraq, DevSecOps üçün bəzi məsləhətlər verəcəyəm. Sistemlərinizin yaradılması prosesinə auditorları daxil etməli və onları öyrətmək üçün vaxt sərf etməlisiniz. Auditorlarla əməkdaşlıq etmək lazımdır. Sonra, yalançı pozitivlərə qarşı tamamilə amansız mübarizə aparmaq lazımdır. Ən bahalı zəifliyi skan etmə vasitəsi ilə belə, siqnal-səs nisbətinizin nə olduğunu bilmirsinizsə, tərtibatçılarınız arasında son dərəcə pis vərdişlər yarada bilərsiniz. Tərtibatçılar hadisələrlə boğulacaq və sadəcə onları siləcəklər. Equifax hekayəsi haqqında eşitmisinizsə, bu, ən yüksək xəbərdarlıq səviyyəsinə məhəl qoyulmadığı yerdə baş verənlərdir. Bundan əlavə, zəifliklərin biznesə necə təsir etdiyini aydın şəkildə izah etmək lazımdır. Məsələn, deyə bilərsiniz ki, bu Equifax hekayəsindəki kimi zəiflikdir. Təhlükəsizlik zəifliklərinə digər proqram təminatı problemləri kimi baxılmalı, yəni ümumi DevOps prosesinə daxil edilməlidir. Jira, Kanban və s. vasitəsilə onlarla işləmək lazımdır. Tərtibatçılar bunu başqasının edəcəyini düşünməməlidir - əksinə, hər kəs bunu etməlidir. Nəhayət, insanları öyrətmək üçün enerji sərf etməlisiniz.
Faydalı linklər
DevOops konfransından faydalı ola biləcəyiniz bir neçə çıxışı təqdim edirik:
- Sergey Berdnikov, Artyom Kaliçkin - Uğur hekayəsi və ya "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - Bir miqyasda DevOps: üç aktda Yunan faciəsi (, )
- Alexander Titov, Kirill Tolkachev -
- Timoti Lister -
Bir peek edin DevOops 2020 Moskva - Orada da çox maraqlı şeylər var.
Mənbə: www.habr.com