Programming ∀

Endi bu masla ham orzu havasda, kotta bollani jentrasiga o’xshgagan.

IAC maslasida qilgan researchlarimdan hulosa deyarli hamma platformlarda configuration qilish ancha noqulay, ayniqsa sizda juda ko'p serverlar va turli component va applicationlar bo'lsa hammasini code bilan manage qilishingiz azob undan azoblisi esa anashu stateni ushlab turish. Nix misolida immutable configlarni ko'rdik mana. Ammo serverlarga mos kelmaydigan joylari bor yani nix pull basedi ishlaydi. Agar manashu narsa push based ishlasachi ? Keyingi masala. Sevimli va qadrli kubernetes to'liq mutable infrastructure. Biz resource management uchun turli resoruce policylar qilib chiqamiz. Turli access controllar vaxakazo policylar qilamiz. Ho'sh bular aniq ishlashiga proof bormi ? Bu savol manda ochiq, hamma holatlar hisobga olingan deya olmayman. Chunki tajribamda man qilgan xatoni deb buzib qo'yganman ko'p narsani. Demak hammasini miyyamda ushlashim kerak. Ho'sh mani miyyamga qancha kubernetes configlari sig'adi ? Ko'p emas-a )) Sizga ham ko'p sig'maydi. Lekin bizda dokumentatsiya aynan shunga yoziladiku... deymiz ammo doyim doc va infrani birga olib yurmaymiz )) Demak bu narsani eslab qolishni yoki proof qilishni ham kuber hal etsin. Masalan trash-app pod uchun max 4G ram ajratishni so'rasam. Agar mumkin bo'lsa aniq ajratsin doyimiy va stabil. Agar bo'lmasa xatolik bersin clusterda buncha resurs yo'qligi haqida. Ahir nima uchun bechora devopslar hammasini kallasida ushlashi kerak? Nega hammasini duplicate qilishi kerak ? Agar hammasi bunday bo'lsa manavi ishlatilinyotgan tooling yanayam ko'p og'riqlarga sabab bo'lyabtiku ))

Agar qanaqadir hcl tushunadigan syntax analyserlar bo'lsa nechi % code duplication ekanini aniqlasa bo'ladi. DevOps stuffda juda ham ko'p muammolar bor, tassavur ham qilolmaysiz. Terraform nisbatan yaxshi narsa, ammo to'nnalab yozilgan yaml filelarni ko'rgan dasturchini mazasi qochadi. Umuman hamma narsalar taxta va bordak. Agar manashunaqa muammolar tog'irlansa bu soha vakillari anchagina baxtli bo'lishadi. O'ylashim bo'yicha bularni ham ma'lum darajada abstraction bilan osonlikcha boshqarsa bo'ladi. Juda ham ko'p automatinlar osongina bitib ketadi. Oldinlari compiler, interpreterlarga umuman language developmentga deyarli ish yo'q deb juda katta xato fikrlagan ekanman. Xozirda manabunaqa holatlarni ko'rib o'zim uchun notes yozib ketyabman skillarni oshirsam manashu muammolarni birortasini aniq hal etaman.

Qaranglar qancha code duplication bor🥲

Manashu narsaga pattern matching qo'sha.

resource "google_cloud_scheduler_job" "version_every_minute"{}

resource "google_cloud_scheduler_job" "version_every_two_minutes"{}

Manashunaqa qisqa va ergonomik code hosil bo'ladi.

resource "google_cloud_scheduler_job" (minutes){
    match minutes{
         "version_every_minute" {}
          "version_every_two_minutes" {}
    }
}

https://github.com/hashicorp/hcl/blob/main/hclsyntax/spec.md

Xojatxonaga ham laptop bilan kiradiganlarni kim ? A) Managerlar B) Project Managerlar C) Product managerlar

A) Quic sababli hamma yoqda muammo. B) Uzoffline sababdan muammo. C) Ikkala javob tog'ri.

Engineerlarni manashunaqa practicelarni qilishga majburlayman agar DevOps or SRE bo'lsam. Agar CTO bo'lsam FPga majburlayman🙂 Shu sabab oddiy backendchi bo'lib yashaganim afzal mansab tegsa o'zimdan ketib qolarkanman )) Ammo OTeL sizga ko'p yordam beradi ishonavering.

Jaeger V2 Unveiled: Distributed Tracing Powered by OpenTelemetry https://horovits.medium.com/jaeger-v2-unveiled-distributed-tracing-powered-by-opentelemetry-be612dbee774 #jaeger #opentelemetry #observability #tracing

Bitta spec qilib olib template based bosaverasiz. Ha boilerplate yaxshi practice emas. Ammo aynan IaC uchun expirement qilib ko'rmoqchiman. Chunki juda ham katta abstraction bo'lmaydi common usecaselarga mos specni o'zi bilan 95% hoaltni yopa olar ekanmiz. Endi shu boilerdan nima kutyabman aytaymi ? 1. Bizga task kelib tushganidan boshlab infrani yetkazib berish vaqtini qisqartirish. Common infralar va distrolar uchun. Expected avg time: 20-30m Ideal: 15m 2. Upgrade, reconfiguration maintenance. Update va upgradelar vaqt olishi mumkin + roolbacklar bilan. Expected avg time: 40m Ideal: 15-30m 3. Managing complexity, katta infra bo'lsa ham kichik bo'lsa ham birxil flowga tushaveradi. O'ylamaymanki bir vaqtning o'zida 1k inventory bo'lib ketadi deb. Kegin statistika bo'yicha juda ham ko'pchilik serverlar popular distrolarda ishlaydi. BSDlarni kamroq uchratasiz. Asosiy qiyinchlik inventory va infra uchun spec yozishda. 4. Spec va Infra docs va requirements bir biriga aniq mos bo'ladi. Faqat o'rtasidagi bog'liqlikni qurish kerak bunga ham yechimlar o'ylayabman. Agar manashu narsani amalga oshirolsam masalan N serverga nginx 1.26 versiya deb spec yozigan bo'lsa demak aniq manashu versiya bo'ladi ! Qog'ozbozlik va amaliyot consistent bo'ladi. 5. Pipelines, barcha infralar uchun alohida pipelinelar qursa bo'ladi yani bitta infra uchun firewall, iptables yana nimadirlar majburib bo'lsa prosto pipelinesga qo'shib ketasiz. PS: Hullas muammo chiqdimi hal qilish va xizmat ko'rsatish eng minimal vaqt oralig'ida bo'lishi kerak. Manashu main goal. Xizmat sifatini esa albatta kallada ushlamaymiz code bilan hal etamiz !

Ansibleni ham biroz odambashara qilib ishlatsa bo'ladi ekan. Hullas manashu yerdagi configlarimdan to'liq inventory generate qilsa bo'ladi )) 1. Yaml lint ishlatish required 2. Paybooklarni generic qilib olish kerek hammasini galxe bo'lsa ham. 3. Default installationlarga manashunga o'xshagan notation qilinsa kegin buni asosida sodda documentation generate qilsa bo'ladi. targets o'ylab topilgan iplar. PS: Expiremental Nix based yechimlar ham ketyabti paralellno. Nixda shunaqa narsalarni module qilib olib bosaverasiz 😊 Faqat Dilivery biroz muammoli, ansibleda push bo'lgani uchun deploy va roolback oson.

Boshlang'ich Dev*Opslar uchun tavsiya perf, tcpdump, iotop shu kabi toolar o'zi bilan ishlashni o'rganing oldin. Ko'pchilik manitoring dashboarlarni ochsa dovdirab qoladi kerak kerak emas narsalar uchun dashboard chizib tashlaydi. Yo'q unaqasi ketmaydi siz frontendchi emassiz dashboard chizib o'tiradigan har bir parametr sizga qanaqadir ma'lumot beradi, endi shu ma'lumot qanchalik o'rinli va foydali ekaniga qarab chizish kerak )) Bu yerda Perfomance Observability mavzusidan ko'p narsa bor. Monitoring uchun esa htop, iotop, iostat vaxakazolardan boshlasangiz bo'ladi. Shularni ishlatib ko'rsangiz boshida qiynalasiz ammo kegin ELK bo'ladimi Grafanami yana boshqasimi hammasini cook qilasiz )) ular oson bo'lib qoladi. https://www.brendangregg.com/linuxperf.html

Manashu narsa zo'rda, linuxda xclip prosto, ptosto 😁 Vault bilan hamma narsaning ham integratsiyasi bo'lmagani uchun haligacha keylarimni olib yuraman.

I love this comment style. Tosh davrida yashagan ekanman.

DevOps yechimlar kerak bo'lsa kelinouradi. Hudoholasa birnecha oydan kegin hammasi tayyor bo'ladi bizda 😎 Loyihangiz yashaydigan zooparkni obodonlashtirib beramiz😊

Based, FPga jiddiyroq kirisha boshlaganimdan kegin Gof, SOLID, Grasp kabi narsalar o’rniga boshqalari keldi va bu conceptlar avvalaridan ancha effective🙂

100%

Bazi narsalarda learning curve sal murakkab bo’layotganini sezdim. Endi notes yozishni odat qilaman self-hosted obsidian va tamam. Va hafta yakunida 1 haftalik notesni qayta o’qiyman.

Microsoft MVP - Most Valaki-salaki Programmer

Point of views - Juda qiziq narsa kuzatganman odatda biror muammoga turli soha vakillari turlicha qarashadi va yechim o'ylashadi. Kecha huddi shunaqa hodisalardan biri bo'ldi. Hullas birqancha dunyoqarashlar va o'rtada aniq konsensus yo'q. Huddiki hamma o'z fikrini o'tkazishga xarakat qilayotgandak. Asilda muammo qolib insonlar bir birlariga qarshi chiqa boshlashdi. Yeg'ilish real hayotda bo'lgani uchun ham bunaqa baxs munozara judayam hunik va bordak bo'la boshladi. Turli dunyoqarash va maqsadli odamlar bir mavzuni discussion qilishi haqiqiy bordakga sabab bo'ldi, toki biroz sovuqqonlik bilan yondoshib hamma aynan bir muammoni hal qilish uchun yegi'lganini hisobga olmaguncha. Manashu suxbatda tushunib yetdim hissiyotlar bilan boshqaruv yoki hissiyotlar bilan qaror qilish umuman bo'lmaydigan narsa. Albatta o'sha davrada turli kasb egalari bor edi, va shu sababdan dunyoqarashlar gradienti sezilib turadi ammo ma'lum toifa odamlarda nafaqat hissiyotga asoslangan yechimlarni balki o'zlari hohlayotgan(o'zlariga moslangan) yechimlarni ham kuzatdim. Hullas muammo barbir hal bo'lmadi 1 soatga yaqin munozara bo'ldi. Kegin taklif berdim qog'oz va ruchkani olib bitta tablega hammaning qisqa fikri va dalilini yozib oldik, kegin boshqa joyga anashu dalillarni hammasini ranked qilib chiqdik prooflarga nisbatan. Kegin har bir dalilni tanqid qildik yani qarshi argumentlar, ana kegin qarshi argumentlarni proof qildik va rank qildik. Manashu itarationdan kegin barcha hissiy fikrlar va yechimlar chetga chiqib ketti. Ohiri 2-3 fikr qoldi. Qolgan fikrlar uchun asosiy contextni topib suxbatni davom qildik. Boshida hamma ishonmagan edi ammo aynan manashu yechim hammani qoniqtirdi va jamoaviy firklashga asoslangan yechimga keldik. Man esa juda hursand bo'ldim sababi birnecha daqiqa oldin bo'layotgan molxona haqiqiy ilmiy majlisga aylandi(Devanniy expertlar majlisi). Eng muhimi muammo yechimi topildi discussion ancha adekvatlashdi.