DevOps Qəbulunda 8 Gündəlik Problemlər və Onları Həll Etmək (Problemlər) - Hissə 1

DevOps artıq İT sənayesində yeni bir söz deyildir; bu, 2020-dir və demək olar ki, hər bir təşkilat mədəniyyətini və metodlarını bu iş üsulları ilə inkişaf etdirmək istəyir və ya çalışır. Bununla belə, belə bir inqilabi dəyişikliyi qəbul etmək asan deyil və həm liderlər, həm də 'edənlər' qarşısında çoxsaylı çətinliklər var; DevOps çox aşağıdan yuxarı və yuxarıdan aşağıya doğru bir hərəkətdir. Sahə işlərində müşahidə etdiyim bəzi ümumi çətinliklər:

  1. Disfunksional mədəniyyət

Şiddətli əmr verən və idarə edən və bürokratik olan mədəniyyətlər iş yerlərini çox dağıdıcı edə bilər. İnsanlar problem və ya bilik və məlumatın artırılması üçün cəzalandırıldığı yerlərdə insanlar bölüşməyə və əməkdaşlıq etməyə mane olacaqlar. Uğursuzluğun qarşısı alınacaq bir şey olduğu görüldükdə insanlar səhvlərini onlardan öyrənmək əvəzinə gizlədəcək və yeni şeyləri sınamaqdan qorxacaqlar.

Mədəniyyəti müəyyənləşdirmək çox çətindir və dəyişdirmək çox çətin görünür. Bir təşkilatdakı insanların dəyərləri və davranışlarıdır və bu insan səviyyəsində həll edilməlidir; yalnız bit və bayt deyil, duyğu və hisslər haqqında danışmağı tələb edir.

2. Dəyişməyə müqavimət

Bir çox insan iş tərzini dəyişməyi xoşlamır; işləmə metoduna alışmışlar və adi qaydalarını və ya proseslərini tez-tez tənzimləmək istəmirlər. Bir çox insan siloslarda işləməyi üstün tutur və başqaları ilə ünsiyyət qurmaq istəməyə bilər və buna görə də DevOps liderləri çevrilmə prosesində tez-tez müqavimətlə üzləşirlər. Britt Andreatta kimi bəzi nevropatoloqlar, insanların təkamül səbəbləri ilə dəyişikliyə müqavimət göstərmək üçün əsaslı tellər olduğuna inanırlar.

Dəyişiklik agentinin və ya bir təşkilatın müqavimət göstərə biləcəyi bir nümunə: ənənəvi olaraq əl ilə sınaq keçirən bir test cihazından test ssenarisini və ya davamlı inteqrasiya boru kəmərindəki addımları avtomatlaşdırması istənə bilər. Əvvəlki əl test ssenarilərini necə avtomatlaşdırmağı və bunun mümkünsüzlüyünü hiss etmələrini öyrənmələri lazım olduğuna görə iş tərzlərini dəyişdirməyə qarşı çıxa bilərlər. Başqa bir nümunə, nəzarət etmək üçün böyük bir test qrupu qurmağa alışmış bir QA meneceridir: onlar testçilərinin təhdid etdiklərini hiss edə bildikləri funksional heyətlərə təşkilati yenidən qurulmanın bir hissəsi olaraq bir neçə komanda arasında paylandığını görə bilərlər. lider və menecer statusu.

3. Görmə aydınlığının olmaması

Bir çox təşkilatlar, DevOps'un vəd etdiyi inkişafları istəyir, lakin DevOps'ların necə qəbul ediləcəyini düzgün planlaşdırmaq üçün çox vaxt yetərli vaxt sərf edilmir. Rəhbərlər, DevOps'ların təşkilati yenidən dizayn baxımından tələb edə biləcəklərini araşdırmamış ola bilər və ya buna qarşı ola bilərlər. Təşkilatlar tez-tez DevOps liderlərini və müdafiəçilərini əsl DevOps mədəniyyətini yetişdirmək və tətbiq etmək üçün liderlik dəstəyi olmadan tək planlaşdırmaq üçün tərk edirlər.

Müvafiq plan və strategiya olmadan DevOps çevrilmələri hədəflərinə çatmağı çox çətinləşdirir. Görmə qabiliyyətinin olmaması DevOps liderlərinin qiymətləndirmə, yol xəritələri və çatdırılma ilə bağlı qərar verməyə gəldikdə dəqiq plan hazırlamağı çətinləşdirir. Həm də aydınlıq olmadıqda daha geniş təşkilat arasında ünsiyyət qurmaq və görmə qabiliyyətini bölüşmək çox çətinləşdirir.

Bəzən DevOps dəyişdirmə agentlərinin idarəetmə və ya C-suite təklif etdikləri DevOpsların qəbul edilməsi üçün uyğun bir plan və strategiya var, lakin bu liderlər DevOps tətbiqinə dair icra planını açıq şəkildə dəstəkləmir və təbliğ etmədikləri təqdirdə DevOps qəbul etmə proseslərini poza bilər.

4. Komandalar əməkdaşlıq etmir

DevOps-da əsas məqsəd Dev, Op və digər komandaların siloslar arasındakı maneələri qıraraq birlikdə işləmələrini təşviq etməkdir. Komandaların öz məqsədləri olacaq; inkişaf qrupu dəyişikliyə və İT əməliyyat qrupu sabitliyə yönəlmişdir. Komandaların hədəflərini təmin etmək, aparıcı DevOps qəbul edənlər üçün əsas problemdir.

Bundan əlavə, bir təşkilat coğrafi cəhətdən dağıldıqda, komandalararası əməkdaşlıq daha da çətinləşə bilər. DevOps və çevik modellər birlikdə yerləşməsini təşviq etsələr də, bu tez-tez praktik və ya hətta mümkün deyil. Bundan əlavə, bir çox təşkilat, vaxt zonası və dil fəsadları səbəbindən çətinliyi artıran potensial olaraq əhəmiyyətli dərəcədə fərqli coğrafi bölgələr üçün test və ya İT əməliyyatları kimi xarici qaynaq işləri görür.

5. Mühitlər standartlaşdırılmamışdır

DevOps mühitində birdən çox proqram və ya xidmət versiyası ilə məşğul olmaq istehsalın yavaşlaması ilə nəticələnə bilər və məhsullarımızdakı səhv və problemlərin artmasına səbəb ola bilər. Standart mühitlərə və ya istehsala bənzər bir test mühitinə sahib olmamaq tez-tez insidentlərə səbəb olur, çünki uyğunsuzluq gözlənilməzliyə səbəb olur. Qeyri-adi tətbiqi mühitinin olmaması müştərilər üçün yeni dəyərin verilməsində əlavə ağrı və gecikmələrə səbəb ola bilər, çünki komandalar, məsələn, ortaq test mühitlərinə girməyi gözləyəcəklər.

6. Vəsaitlər mübahisədədir

İnkişaf və İT əməliyyat qrupları tez-tez müxtəlif alətlərdən istifadə edirlər, lakin çox vaxt eyni işi etməyə və ya eyni işi idarə etməyə çalışırlar. Çağırış düzgün vasitənin tətbiq olunduğundan və bütün komandaların hədəfləri ilə şirkətin hədəflərinə uyğun olduğundan əmin olmaqdır.

Alət seçimi insanların (çox vaxt emosional) üstünlükləri olduğu üçün mübahisəli bir sahədir. Bir vasitə seçildikdən sonra insanlar onu istifadə etməyi öyrəndilər və bunun tərkibində çox miqdarda məlumat və ya xüsusi iş axını var, buna görə də bir vasitəni dəyişdirmək çətindir - hətta komandaların və şirkətin məqsədlərinə daha yaxşı uyğunlaşan başqa birinin olduğunu müəyyənləşdirdikdə.

7. Buraxılış İdarəetmə Gecikmələrə səbəb olur

Ənənəvi olaraq, təşkilatlar bir layihəyə əsaslanan bir yanaşma istifadə edərək böyük xüsusiyyətlər buraxdılar. Bu relizlər tez-tez komandaların kitablarını yerləşdirdiyi bir buraxılış təqvimindən istifadə edərək mərkəzləşdirilmiş bir buraxılış qrupu (əksər hallarda həftə sonları iş tələb edir) ilə əlaqələndirilir. Bu buraxılışlar çox vaxt əl ilə və ya bir dəstə skriptlə aparılır, yalnız onları buraxan menecer başa düşür. Bütün bunlar, relizlərin nadir hallarda baş verdiyini və aradan qaldırılmalı olan problemlərin olma riskinin yüksək olması deməkdir. Komandalar tez-tez problemin niyə baş verdiyini öyrənmədən və tədrisin yenidən təşkilata daxil olmasını təmin etməkdən daha çox problemlərin həllinə yönəldilirlər. Layihə qrupları kimi çox vaxt canlı yayımlanan tarixdən sonra yayılır və həyata keçirilmədən sonrakı araşdırma, səylərin nəzərdə tutulan nəticələrə səbəb olub olmadığını yoxlamır.

8. Manuel test çətin və vaxt aparıcıdır

Əl ilə sınamaq çox vaxt aparır və tez-tez ayrı-ayrı qruplarda müştəriyə dəyər axınının gecikməsini yaradan ayrı qruplar tərəfindən aparılır. Bundan əlavə, minimum vahid testini avtomatlaşdırmadan əsl davamlı inteqrasiya etmək mümkün deyil - ideal olaraq inteqrasiya və istifadəçi qəbulu testləri də avtomatlaşdırılacaq. Avtomatik test, xüsusilə bir təşkilatda bu işi görməyə qadir mənbələr olduqda, böyük və hədsiz bir iş kimi görünə bilər. İnsanlar tez-tez əl əməyi tələb edildikdə imtahanın bahalı olduğunu qəbul edirlər və investisiya qoyuluşunu məhdudlaşdırmağa çalışırlar - bu da keyfiyyətsiz və iş vaxtının aşağı olmasına səbəb olur.

Nəticə

DevOps qəbulu əhəmiyyətli vaxt tələb edən bir səyahətdir. Təşkilatlardan dinamik və davamlı öyrənmə tətbiq etmələrini tələb edir. Bu səkkiz əsas problem barədə çox erkən mərhələdə məlumatlandırılması, problemləri qabaqcadan görməyə və səyləri prioritetləşdirməyə kömək edəcəkdir. Bu blog seriyasının 2-ci hissəsində. Bu çətinliklərin necə aradan qaldırılacağını araşdıracağam və buraya tıklayaraq oxuya bilərsiniz.