Akhmad’s DB


Kanal geosi va tili: ko‘rsatilmagan, ko‘rsatilmagan
Toifa: ko‘rsatilmagan


Ushbu kanalda IT va Dasturlashga aloqador mavzularda subyektiv fikrlarimni bayon qilaman.

Связанные каналы  |  Похожие каналы

Kanal geosi va tili
ko‘rsatilmagan, ko‘rsatilmagan
Toifa
ko‘rsatilmagan
Statistika
Postlar filtri


Yana bir fikr kelyabti.

Achitecture must be Open source.

Mani fikrimcha aynan manashu narsa learning va optimizing purpose uchun juda ham effektiv.

Massalan qandaydir tizim o'zining arxitekturasini ochiq qildi deylik. Aynan shunaqa tizim ustida ishlayotgan boshqalar o'z fikrlarini bildirishlari yoki shunaqa tizim qurmoqchi bo'lganlar o'rganishlari mumkin.


Qiziq maqola ekan, Lean4 bilan salgina tanishganimdan kegin aynan amazon ham shundan ko'p foydalanishiga guvoh bo'lgan edim. Kegin @keilambda TLA+ kabi narsalardan ham foydalanishini aytdi ))

Fikrimcha dasturlash sohasida aynan manashunaqa narsalarga extiyojlar ko'payabti. Chunki mavjud bo'lgan traditional yechimlar doyim ham o'zini oqlamayabti. Masalan mani tajribamda bir tizim uchun architecturedan tortib hamma narsani documented qilish va uni doyim update qilib yurish juda qimmatga tushgan edi. U yetmaganidak turli dunyo qarashdagilar turlicha tushunadi. Masalan requirements bo'yicha QA test qiladi ammo fichani bug deydi... Yoki yozilgan testlarda exeptionlar barbir chiqadi.

Prooflar bunaqa muammolarning davosi. Ammo ko'pchilik learning curve deb bunaqa narsalardan uzoq turadi. Lekin business uchun aynan manashunaqa yechimlar arzonroqga ham tushadi deb o'ylayman.

Masalan architectlar uchun TLA+, Alloy6 kabi toolar juda ham foydali instrument. Sababi siz qanaqadir diagramlar bilan emas balki aniq propositionlar bilan define qilasiz tizimni. Diagramlar sizga aniq muammoni ko'rsatmaydi siz shunchaki UML chizasiz. Ammo UML shunchaki rasm u bilan nimadirni isbotlash yoki tekshirish qiyin yani inson faktoriga asoslangan.

Ammo biz 21 asrdamiz, xozirda hamma narsa juda complex bo'lib ketgan. Barcha edge caselar inson miyyasiga sig'maydi. Shu sababdan bizga boshqacharoq narsa kerak. Bu narsalar bizni xato qilishdan saqlashi yoki xatoyimizni ko'rsatishi kerak. Fikrimcha bunaqa point of view bizga ancha qulayroq va effektivroq deb bilaman.


TLA+ at amazon: https://awsmaniac.com/how-formal-methods-helped-aws-to-design-amazing-services/

Lean4 at amazon: https://www.amazon.science/blog/how-the-lean-language-brings-math-to-coding-and-coding-to-math




Endi sekin directionchani olib manashu concept ustida ishlayman. O'ylaymanki bu ideyalar DevOpslar uchun yoqimli ergonomik tilda ishlash imkoniyatiga sabab bo'ladi. Shu sababdan IaC mavzusida sizlarni nimalar qiynasa uyalmasdan aytaveringlar 🙂


imports {
DebianConfs,
RedhatConfs
}

type OS = Debian | RedHat

configurations Debian = DebianConfs
configurations RedHat = RedhatConfs


Haskellga o'xshab qoldi-a ))

Hullas bu masalada ancha ideyalar kelyabti.


imports {
DebianConfs,
RedhatConfs
}

type OS = Debian | RedHat

configurations = match os {
Debian => DebianConfs
RedHat => RedhatConfs
}


Bunisi esa rustga o'xshaydi.

Qisqasi ADT va Patternmatch bo'lsa tassavur qiling siz Os tipiga yangi member qo'shsangiz compiler error beradi sababi uning configurationlarini defiine qilishiz shart. Bu esa manabunaqa holatlarda esdan chiqarmaslikga yordam beradi. Configlarni esa module qivolib bosaverasiz.


Barbir miyyada eslab qolishingiz kerak nima qo'shgan qo'shmaganizni.


Xitoyliklar qilayotgan kernel OSS ekanmi 🤔 Tushunishimcha rustda ekan to'liq.

Bu mavzuda contextda borlar bilganlarizni ulashing ularni kerneli qanday ekani qiziq ))


Multi master k8sda etcd external etcd ))

Manimcha ko'pchilik clusterni setup qilganida k8s componentlarga etibor qilmaydi, oqibatda biror muammo chiqsa qiynalib yuradi. Shaxsiyga manashunaqa masalada yozishgan edi. K8s eslab olishga biroz vaqt ketti va ohiri mana yechim.

Multi master clusterda eng birinchi target etcdni external olib chiqamiz. Bu aynan etcd o'zi bilan direct ishlashga va kuberga bog'liq bo'lib qolmaslikga yordam beradi intensivlikni oshiradi. Mani tajribamda bunaqa yechim ko'proq foydali bo'lgan pod ichiga tiqanimdan ko'ra. Ammo support ham alohida bo'ladi...

Qo'shimcha resurs:

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/


Haskell kundan kunga baqquvatlashib boryabti haliyam😎


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

414 0 2 11 28

A) Quick sababli hamma yoqda muammo.
😎 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.


Sysadmin Tools 🇺🇦 dan repost
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.


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.

20 ta oxirgi post ko‘rsatilgan.