Hazırda biznes o qədər sürətlə inkişaf edir ki, bu sürətə uyğunlaşmaq üçün yeganə yolumuz varsa, o da DevOps-dan keçir. Amma hər kəsdə bu yol fərqlidir, ona görə də DevOps-un tətbiqinə biznes prosesdə baxmaq lazımdır."
"DevOps - qaydalar toplusu deyil ki, onu istifadə edəndən sonra hər şey əla olsun. Bu nə yanaşmadır? Onu dəyişmək lazımdır. Bax onda əla olacaq."
"DevOps - sehrli çubuq deyil. Bu, biznesə müəyyən tələblərə cavab verməyə kömək edən texnologiyalar və metodologiyalar toplusudur."
Məqaləni
... ona görə girişsiz, salamsız-kəlamsız başladım ki, düşüncə yolunuzda bəri başdan sərhədlər qoyum. Mövzu genişdir və şaxələr sizi çaşdıra bilər. DevOps ilə əlaqədar tapıb oxuduğum məqalələrdən o parçaları ona görə ön plana çəkdim ki, burada oxuyub səhv anladığınız və ya DevOps barədə eşidəcəyiniz fikir sizi səhv yönləndirdikdə bu "parçalar" sizi doğru düşüncəyə çəkə bilsin. Çünki bir çoxları DevOps-un sadəcə köhnə sistem administratorunun yeni adı olduğunu zənn edirlər. "Əvvəl kabelləri taxıb-çıxarırdı, indi düymələri basır, kabellər buludda taxılıb-çıxarılır" kimi yalnış fikirlər, və s və s.
DevOps-un nə olmadığını dəqiq anladınızsa DevOps-un nə olduğuna artıq keçə bilərik deməkdir.
Tarixdən başlayaq
Belçika - 2007-ci il. Patrik Debua adlı gənc IT-ni hər tərəfli öyrənmək istəyir. O, konsultant idi, amma vakansiyaları seçəndə elə edirdi ki, IT-nin bütün sahələri barədə bilik toplaya bilsin. Bir gün o, böyük data mərkəzinin köçürülməsi ilə bağlı dövlət işinə girir. Patrik-in əsas işi testləmə idi və o tez-tez developer-lər (dev) qrupu ilə təminat işinə baxanlar qrupunun (ops) arasında qaçhaqaçda qalırdı.
Proqramçılar ilə təminatçılar arasındaki fərq Patrik-i həmişə düşündürürdü. Bu layihədə isə bu fərq maksimal dərəcədə özünü göstərirdi. Ona görə də O, bir gün tərtibat metodologiyaları ilə işləməli olurdu, növbəti gün isə xidmət düzgün çatdırılırmı, hansı problemlər yaranır və onlarla mübarizə aparılmasına baxırdı. Patrik bu məsələdə nələrinsə səhv getdiyini anlayırdı. O, yaxşı, daha yaxşı yolun mütləq olmasına əmin idi, amma dev ilə ops arasında kilometrlər keçirdi və hara baxsan konflikt, konflikt, konflikt.
Keçək 2008-ə, Toronto şəhərinə - Agile konfransına.
Andrew Shafer divarda BOF sessiya ideyasını paylaşır. Dev və Ops barədə həmfikir olanlar üçün "çevik infrastruktur" tədbirini elan edir. Tədbirə cəmi bir nəfər gəlir. Düz tapdınız, bu bizim dostumuz Patrik-dir. Amma tədbirə həqiqətən, hərfi mənada, yalnız bir nəfər gəlmişdi. Hətta Andrew özü də öz sessiyasını buraxır. Heç bir "feedback" almadığı üçün düşünür ki, tərtibat ilə təminat arasındakı məsafələri aradan qaldırmaq heç kəsə maraqlı deyil. Amma Patrik konfransa Scrum istifadəsi barədə təqdimat (.ppt) ilə gəlmişdi. O həmfikir tapa bildiyinə, onunla eyni problemi düşünənlərin ortaya çıxmasına çox sevinmişdi. Patrik, Andrew-nu axtarıb tapdı və onlar çox uzun bir müzakirə apardılar. Axırda həmfikir insanları toplamağa qərar verdilər.
Kontekst barədə qısaca
"Agile" metodologiyaları durmadan inkişaf edirdi. Və bütün cəmiyyət "deployment" məsələlərinə qədərki prosesi təkmillləşdirirdi. Təminatı isə demək olar ki, düşünən yox idi. Məhsulun yaradılışı durmadan operativləşirdi, sürət isə getdikcə artırdı, mütəxəssislər yetişirdi, amma bütün bunlar məhsul hazır olana qədər idi. Təminat tərəfdə heç nə yerindən tərpənmirdi. Məhsulun istifadəçiyə çatdırılması, istifadə zamanı baş verənlər, istifadəçinin razı və ya narazı olduğu məqamlar, texniki xətalar və s. Bunlar üzrə işin modernləşməsi üçün heç kəs ideyalar təklif etmirdi. Nəticədə məhsul çox gözəl bir formada hazırlanıb müştəriyə təqdim olurdu və sonrakı taleyi üzüaşağı gedirdi. Ona görə də, Andrew və Patrik Google Groups-da "Agile Systems Administration" qrupunu yaradırlar. Qrupda maraqlı söhbətlər olurdu, amma qrupun trafiki həqiqətən çox aşağı idi.
DevOpsDays
Sürətlə keçirik 2009-a. John Allspaw və Paul Hammond birgə "Flickr"da işləyirlər. 23 iyun "O'reilly's Velocity Сonference"da San-Xose şəhərində günümüzdə məşhur olan "10-plus deploys per day: dev and ops cooperation at Flickr" çıxışını ilk dəfə təqdim edirlər.
Bizim Patrik isə evdədir. Canlı yayım vasitəsi ilə çıxışa baxır. Patrik deyir - "Budur o!". Twitterdə etdiyi paylaşımda "Velocity"yə getmək istədiyini bildirir. Ona Belçikada öz "Velocity"sini yaratmağı təklif edirlər. Patrik ideyanı tutur, və planladığı tədbiri elan edir: Ghent şəhərində 2009-cu il 30-31 oktyabr tarixlərində tərtibatçılar və sisadmin-lər bir araya toplanacaqdılar.
Tədbirə isə ad qoymaq lazım idi. Başlıqda həm "dev" həm də "ops "sözləri olmalı idi. Və Patrik DoD akronimini "dead on delivery" ifadəsini xatırlatmasına görə bəyəndiyi üçün tədbirin adını DevOpsDays elan edir .Tədbirə çox adam gəldi. Twitterdə isə simvol limiti olduğundan, insanlar xəsislik edərək #DevOpsDays əvəzinə #DevOps yazırdılar.
Şəbəkə mühəndisi və kibertəhlükəsizlik peşəsinə yiyələn - daxil ol
DevOps sözün əsl mənasında tutuzdurdu! 2010-da ABŞ-da da DevOps tədbirləri keçirilməyə başlandı. Bu, adi ideya və təcrübə paylaşımı tədbirləri kimi deyildi. Buraya gələn insanlar IT-nin Enterprise-da necə işləməli olduğunu deyirdilər. Onlar təməldə hər şeyin səhv olduğunu və IT-nin inkişafı üçün oyunun qaydalarında ciddi dəyişikliklər etmək lazım olduğunu deməyə başladılar. Sonra "blogpost"ların sayı durmadan artmağa başladı. Parodik mahnılar çıxdı, videolar, satira, sarkazm və s. Məsələ böyüdükcə böyüyürdü. Bu, həqiqətən də çox böyük bir hərəkat halına gəlmişdi. Amma analitiklər də, vendorlar da ənənəvi "enterprise"lar da onları saymazdan gəlirdilər. Və bu laqeyd yanaşma, hərəkatı daha da gücləndirirdi.
Maliyyəçilər IT-ni sevmirlər. Onlar ona yalnız alət kimi baxırdılar. Marketoloqlar isə həmişəki kimi yalnız məhsulun satıcıdan müştəriyə qədər getdiyi yol ilə maraqlanırdılar. Arxada nə baş verdiyi və ya bir müddət sonra nə baş verəcəyi onları maraqlandırmırdı. Ona görə də bu hərəkat proqramçı olmayanların gözündə sadəcə gülüş oyadırdı.
Cavab özünü çox gözlətmədi. DevOps cəmiyyəti yeni "best practices" alətlərini meydana qoydu. Alətlərin maraqlı adları var idi. Puppet, chef, vagrant, juju, rundeck, logstash, fpm (tapın görək, fpm-daki f hansı məşhur təhqiri bildirir). Bu alətlərin məzəli adları olsa da, əslində ciddi silah kimi idilər. Adi "legasy" həlli bunların yanında heçnə idi. Bu alətlər cəmiyyətin artefaktları kimi idi. Onlar gələcək barədə xəbər verirdilər. Amma kənar şəxslərə bunlar sadəcə oyuncaq kimi görünürdü. Lakin bu yeni oyuncaqların parlaqlığı o qədər gur idi ki, analitiklər qısa zamanda burada ciddi hadisələrin baş verdiyini anladılar və müzakirələrə qatılmağa başladılar. Əvvəl "Red Monk"-dan Michael Cote gəldi, sonra "The 451 Group"-dan Cey Layman, daha sonra "Gartner"-dan Cameron Haight.
2011 - Cameron öz təqdimat faylına (.ppt) yeni bir slayd əlavə edib onu "Enterprice" IT-mağazalara və vendorlara göndərir.
Slaydda DevOps hərəkatından danışılırdı. Cameron proqnoz edir ki, 2015-ci ildə DevOps bulud adlanan texnologiyaları ilə maraq cəlb edən dar strategiyadan təkamül edib, hər kəsin istifadə edəcəyi həllə çevriləcək və "Global 2000 Organizations"-un 20%-ni tutacaq. Əgər siz hələ heçnə başa düşmədinizsə asanlaşdırım. Yəni, Cameron qeyd edirdi ki, "DevOps partladacaq, maraqlanın!"
Niyə tarix oxuduq və nə öyrəndik?
Birincisi - DevOps-u nə vendorlar, nə də ki analitiklər yox, praktiklər fikirləşib. Biz - proqramçılar bilirik ki, vendor və ya analitik "mesajı" tutub insanlara bərbad realizasiya təqdim etməyə çalışanda cəmiyyət onun üstündən xətt çəkməyin bir yolunu həmişə tapır.
İkincisi - Bu tarix bizim yadımıza salır ki, DevOps nə bir əşyadır, nə spesifikasiya, nə standart, nə də peşə adı. DevOps - proqramçı cəmiyyətinin səsidir, təcrübə əsasında formalaşmış hərəkatdır. Bu laqeyd qala bilməyənlərin, yığışıb nəyin işlədiyini, nəyin zəif olduğunu müzakirə edərək, biznes özü istəmədən onun gələcəyini düşünüb onun yaradıcıları sevməyən satıcıların işini asanlaşdıran insanların hekayəsidir.
Həmçinin tarix bizə DevOps-un desentrallaşmış və açıq olduğunu xatırladır. İstər təcrübə paylaşan tərəf olsun istərsə də sual verən - siz həmişə xoş qarşılanacaqsınız. Hərəkat belə başlayıb və belə də davam edir.
Mütəxəssislər
Tarixini anladıq. Nə olduğunu öyrəndik. Bəs bu sahədə mütəxəssis adlandıra biləcəyimiz şəxslər kimlərdir? Bu hissəni yazmaq üçün oxuduğum məqalələrin hamısı oxucudan DevOps-u sisadmin zənn etməmələrini xahiş edib, tələb olunan altsahələri sadalayırlar (hə, birdə ki, hamısı durmadan "docker" "docker" "docker" deyirlər). Mən isə sizinlə Quora-dan tapdığım bir cavabı paylaşıram:
"Bulud texnologiyaları ilə işləmək və DevOps mövzusu ilə məşğul olmaq çox xoşuma gəlir. Çox vaxt bu termini səhvən sistem proqramçılarının izahı üçün və ya ən pisi, sistem administratorunun yeni adı kimi istifadə edirlər.
Milli.Az technote.az-a istinadən bildirir ki, DevOps sözünün mənası başqadır, amma karyera yüksəlişi baxımından bu izah "müasir" sistem proqramçısının nə ilə məşqul olduğu barədə danışır. Deməli, sən developersən və proseslər ilə işə keçmək istəyirsən. Burda səni sürpriz gözləyir. Məsələ "Arch Linux" yazıb "Perl" öyrənməkdə deyil. Gəlin dəqiqləşdirək ki, Devops adamı kimdir və kim deyil?
DevOps sahəsində iş nələrdən ibarətdir:
• Proqram Təminatının yaradılması;
• Alətlərin yaradılması;
• İnfrastrukturun layihələndirilməsi;
• Mütəmadi olaraq çətin tapşırıqların həll olunması;
• Miqyaslaşdırılma, çünki vacibdir;
• *NIX; • Monitorinq;
• Virtuallaşdırma;
• Gecə saat 2-də işıqlar sönsə oyaq olmaq;
• Texniki xidmət (məsələn virtual hostda yaddaş itkisi probleminin həll olunması);
• Tərtibatın çevik metodologiyası;
• PT-nın buraxılışlar dövrlərinə nəzarət;
• Avtomatlaşdırma, avtomatlaşdırma və yenə də avtomatlaşdırma;
• Metrikalar/hesabatlar (monitorinq ilə paralel gedir);
• Layinənin SCM (git, Mercurial, svn və s) üçün budaqlarının və relizlərinin istifadəsi üzrə planın tərtib olunması;
• İnfrastruktur təhlükəsizliyi;
• Bulud texnologiyaları;
• Optimizasiya/incə sazlama;
• Testləmə və yüklənmə/güclülük həcmlərinin ölçülməsi;
• Konfiqurasiyanın idarə olunması (Puppet, Chef, Ansible və s);
• Autentifikasiya servislərinə nəzarət;
• Paketlərin idarəsi üçün sistemlər;
• Əmr sətri ilə işləmək bacarığı (awk);
• Yüklənmənin balanslaşdırılması/ proxy-ləşdirmə (xidmətlər, sistemlər, komponent və proseslər üçün);
• CI/CIT/CD - Kəsintisiz inteqrasiya, inteqrasiyalaşdırılmış testləmə və yeni versiyaların açılması (deploy);
• Verilənlər bazaları (SQL, NoSQL, fərq etmir);
• Sistemlər üzrə peşəkarlıq (şəbəkə, hard disc-lər/fayl sistemi/operativ yaddaş/sistem yaddaşı/prosessor).
DevOps sahəsində işə aid deyil və səhv düşünülür:
• Asanlıq (PT tərtibatı ilə müqayisədə)
• Proqramlaşdırmaya ehtiyac olmaması;
• Kompüterinə Linux yazıb öz sevdiyin ƏS ilə vidalaşmaq;
• PT tərtibatçılığından "daha marağlı" iş.
• Yepyeni iş sahəsi.
Özünüzü DevOps developer olaraq inkişaf etdirmək üçün bir neçə addımları atmalısınız.
DevOps-a ehtiyacı olan şirkətdə müsahibədən keçmək - Əgər səni işə götürsələr, sən proseslərlə işləməyi tez öyrənəcəksən. Çox tez. Əks halda səni qovacaqlar. Əgər səni qovmasalar, sən peşəkar DevOps-developer olmağın üçün nəyinsə çatışmadığını anlayacaqsan.
PT (Proqram təminatı) yaradılışı üzrə biliklərini istifadə edərək alətlər yaratmağı öyrənməlisən. "OpenStack"ı araşdırmalısan. Komponentlərin fərqlərini və zəruri tərəflərini anlamalısan.
Əməliyyatlar ilə əlaqəli bütün proseslərdə iştirak etməlisən: Açılma, miqyaslaşdırma və s. Əgər sənin komandan bununla məşğul olmursa (məsələn, bu işləri əməliyyatlar şöbəsinə göndərirlər), əməliyyatlarla işləyən insanların işinə baxmalısınız.
Təcrübə lazımdırmı? - Mən bu sualı çox vermişəm özümə. Mən tərtibatçılıqla başlamışdım, və bir ildən az müddətə DevOpS-tərtibatçı oldum. Mənim yüksək alqoritmik biliklərim yox idi, amma development təcrübəm yaxşı idi. Yaxşı developer hər şeydə yaxşıdır: Həm PT-nın yazılmasında, həm də onun açılmasında.
Sistemlərin çətinliyini anlayıb onların bir-birinə olan təsirini intuitiv dərəcədə başa düşmək lazımdır."
Tarixini öyrəndik, işini anladıq. Son olaraq...
"Agile" yarananda biznes adamları IT insanlarını necə düzgün idarə etmək lazım olduğunu öyrəndilər. Layihə Menecerləri "Scrum" kimi metodologiyalar ilə məhsulun yaradılış prosesini sürətləndirdilər. Amma bu yanaşmalar işin yalnız müəyyən bir problemini həll edir. Çünki onlar proqram ilə birgə proqramçını da bir alət olaraq təsvir edir.
DevOps yaradacıya onun fərd olduğunu göstərdi. DevOps iş barədə yox, işçi barədə olan məsələdir. Proqramçılar fərd olduqlarını və riyazi olaraq, biznesi hətta biznes adamlarından daha çox anladıqlarını nümayiş elədilər. Nəticə olaraq biz Bulud sistemlərinin, web-in, app-ların, iOT-un sürətlə inkişafını gördük. Dünya 5-10 addım taha tez önə getdi. Məqaləni elə başlıqdakı cümlə ilə bitirmək istəyirəm. Proqramçıları dinləsəniz də dinləməsəniz də, onlar dünyanı dəyişirlər. Çünki onlar, işinizin içini bilən insanlardırlar.
