DevOps və ya maaşlarımızı necə itirdiyimiz və İT sənayesinin gələcəyi

Bugünkü situasiyada ən acınacaqlısı odur ki, İT tədricən adambaşına düşən öhdəliklərin sayında “dayan” sözünün olmadığı bir sahəyə çevrilir.

Vakansiyaları oxuyanda bəzən hətta 2-3 nəfəri yox, bütöv bir şirkəti bir adamda görürsən, hamı tələsir, texniki borc artır, yeni məhsullar fonunda köhnə miras mükəmməlliyə bənzəyir, çünki ən azından onun kodda doklar və şərhlər, yeni məhsullar işıq sürəti ilə yazılır, lakin sonda onlar yazıldıqdan sonra bir il istifadə edilə bilməz və çox vaxt bu il qazanc gətirmir; üstəlik, "bulud"un xərcləri. ” xidmətinin satışından yüksəkdir. İnvestorların pulları hələ işləməyən, lakin artıq işləyən kimi onlayn buraxılmış bir xidmətin saxlanmasına sərf olunur.
Nümunə olaraq: köhnə oyunun remasteri sənayenin bütün tarixində ən aşağı reytinqləri alan tanınmış bir şirkət. Bu məhsulu alanlardan biri də mən idim, amma indi də bu məhsul dəhşətli işləyir və nəzəri olaraq bu formada satışa çıxmamalı idi. Geri ödənişlər, reytinqlərin düşməsi, xidmətlərin işi ilə bağlı şikayətlər üçün forumlarda istifadəçilərin çoxlu qadağaları. Yamaqların sayı heyrətamiz deyil, qorxuncdur, amma yenə də məhsul istifadə edilə bilməz. Əgər bu yanaşma 91-ci ildən inkişaf edən şirkət üçün belə nəticələrə gətirib çıxarırsa, yeni fəaliyyətə başlayan şirkətlər üçün vəziyyət daha acınacaqlıdır.

Ancaq biz bu yanaşmanın nəticələrinə xidmət istifadəçisi tərəfindən baxdıq və indi işçilərin qarşılaşdığı problemlərə baxaq.

Mən tez-tez DevOps komandalarının mövcud olmaması, bunun bir metodologiya olduğu və s. ifadəsini eşidirəm, amma problem ondadır ki, şirkətlər nədənsə noks, dba, infrastruktur və tikinti mühəndisləri axtarmağı dayandırdılar - indi hamısı tək bir DevOps mühəndisidir. . Təbii ki, ayrı-ayrı şirkətlərdə hələ də belə vakansiyalar var, lakin onların sayı getdikcə azalır. Çoxları bunu inkişaf adlandırdı, mən şəxsən bunda deqradasiya görürəm, bütün sahələrdə bilik səviyyəsini yaxşı saxlamaq mümkün deyil və eyni zamanda 8 saatdan çox işləməyə nail olur. Təbii ki, bunlar fantaziyalardır. Reallıqda bir çox İT işçiləri 12 və ya 14 saat işləmək məcburiyyətində qalır, onlardan 8-i maaş alır.Və çox vaxt istirahət günləri olmur, çünki “Mənə tapşırıq verilib, sənədlər və ya əyriləri yoxdur, xidmət pula başa gəlir”. və buludda 1 səhv üçün, əsasən bir neçə ay ərzində maaş ala bilməyəcəksiniz, xüsusən də fərdi sahibkar kimi işləyirsinizsə. Məsuliyyətlərin bölüşdürülməsi ilə yanaşı biznesdə öz sözümüzü itiririk; Mən getdikcə daha çox menecerlərin onlar haqqında heç nə anlamadan inkişaf proseslərinə qarışması, biznes məlumatlarını və tətbiqin işini qarışdırması faktı ilə üzləşirəm. nəticədə xaos başlayır.

Xaos başlayanda biznes günahkarı tapmaq istəyir və burada onlara universal bir günahkar lazımdır; günahı 10+ adamın üzərinə yıxmaq çətindir, ona görə də menecerlər mövqeləri birləşdirir, çünki bir mütəxəssisin məsuliyyəti nə qədər çox olarsa, o qədər asan olar. səhlənkarlığını sübut edir. Çevik şəraitdə isə “günahkarı” tapmaq və şallaqlamaq idarəetmədə biznesin aparılması üçün bu metodologiyanın əsasını təşkil edir. Agile IT-dən çoxdan çıxdı və onun əsas konsepsiyası gündəlik nəticələrin tələbinə çevrildi. Problem ondadır ki, yüksək ixtisaslaşmış mütəxəssis həmişə gündəlik nəticələrə malik olmayacaq, yəni hesabat vermək daha çətin olacaq və bu, müəssisələrin “hər şeydə ekspertlər” istəməsinin başqa bir səbəbidir. Amma əsas səbəb, təbii ki, maaşdır - bütün dəyişikliklərin əsas səbəbi budur, bonus xatirinə insanlar özləri və o oğlan üçün işləməyə razılaşdılar. Ancaq sonda, digər sahələrdə olduğu kimi, indi daha çox sayda xidmət üçün daha az ödəniş üçün sadəcə bir məsuliyyətə çevrildi.

İndiki vaxtda hətta tərtibatçıların da yerləşdirməyi bacarmalı, DevOps mühəndisi ilə yanaşı infrastruktur üzərində işləməli olduğunu bildirən məqalələri tez-tez görə bilərsiniz, lakin bu nəyə gətirib çıxarır? Düzdü - xidmətlərin keyfiyyətinin aşağı düşməsinə, tərtibatçıların keyfiyyətinin aşağı düşməsinə. Cəmi 2 gün əvvəl tərtibatçıya izah etdim ki, müxtəlif hostlardan yazıb oxuya bilərsən və onlar ağzından köpük çıxarıb sübut etmək üçün heç vaxt belə bir şey görmədiklərini, lakin parametrlərdə orm host, port, db, user var. , parol və bu qədər…. Ancaq tərtibatçı yerləşdirmələri necə idarə etməyi, yams yazmağı bilir ... Amma o, kodda vahid testləri və şərhləri artıq unudur.

Nəticə etibarı ilə biz aşağıdakıları görürük - daimi iş vaxtından artıq işləmək, iş vaxtından kənar problemlərin həlli yollarını axtarmaq, həftə sonları daimi məşq etmək və gəliri artırmaq üçün deyil, özümüzü ayaqda saxlamaq üçün. Tərtibatçılar DevOps mühəndisinə CI/CD ilə kömək etmək məcburiyyətində qalırlar və əgər tərtibatçının vaxtı yoxdursa, o, ilişib qalmağa başlayır və menecerlər beyinlərini kompostlamağa başlayırlar və bu, işdən artıq işləmək istəyini artırmağa kömək etmirsə, sonra cərimələr və cərimələr tətbiq edən şəxs geridə Everest ölçüsündə texniki borc buraxaraq yeni iş axtarır, nəticədə borc tərtibatçılar arasında böyüməyə başlayır, çünki köhnə və ya yeni DevOps mühəndisinə kömək etməyə vaxt tapmaq üçün daha az refaktorinqlə kod yazmağa məcbur olurlar və menecerlər hər şeydən razıdırlar, çünki günahkar oradadır və o, dərhal görünə bilər, bu da əsas qayda deməkdir. Çevik idarəçilik izlənildi, günahkar tapıldı, qamçılanmasının nəticələri görünür.

Mən bir dəfə ITGM-də “biz “yox” deməyi öyrənəndə” təqdimatını etdim - onun nəticələri çox açıq idi. Çox sayda insan bu sözün tabu olduğuna inanır və biz belə düşünməyi dayandırana qədər problemlər daha da böyüyəcək.

Bu məqalə qismən məndən ilham aldı bu məqalə, lakin sonralar bunu daha az nəzakətli sözlərlə təsvir edə bilərəm.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Bir işəgötürənin sizinlə bir neçə nəfəri əvəz etməyə çalışdığı zaman iş yerində rastlaşmısınızmı?

  • 65,6%Bəli, mən buna mütəmadi olaraq rast gəlirəm183

  • 5,4%Bəli, 1 dəfə rastlaşdım15

  • 15,4%Diqqət etmədim43

  • 13,6%Mən iş həvəskarıyam, özüm işdən artıq işləyirəm38

279 istifadəçi səs verib. 34 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com

Добавить комментарий