Platforma va DevOps strategiyasi (Platform & DevOps Strategy)

Endi arxitektor uchun juda amaliy va production’ga yaqin mavzu:

Platform & DevOps strategy - kod yozilgandan keyin uni qanday build qilish, test qilish, deploy qilish, kuzatish, rollback qilish va infrani boshqarish strategiyasi.

Bu mavzu ichida quyidagilar bor: CI/CD pipeline design, GitOps, Infrastructure as Code, multi-region deployment patterns, blue-green & canary deployments, FinOps.

1. Platform & DevOps Strategy nima?

Developer odatda shunday o‘ylaydi:

Kod yozdim → Gitga push qildim → serverda ishlasa bo‘ldi

Arxitektor esa shunday o‘ylaydi:

Kod qanday build bo‘ladi?
Testlar qayerda yuradi?
Security scan bormi?
Docker image qanday yaratiladi?
Deployment avtomatikmi?
Rollback necha daqiqada bo‘ladi?
Production config qayerda turadi?
Secretlar qayerda saqlanadi?
Monitoring va alert bormi?
Infrastructure kod bilan boshqariladimi?
Cloud xarajat nazorat qilinyaptimi?

Ya’ni bu mavzu faqat "DevOps server sozlaydi" emas. Bu - software delivery system architecture.

2. Platform nima?

Platform - developerlar application’ni tez, xavfsiz va standart tarzda production’ga chiqarishi uchun ichki texnik muhit.

Masalan platform quyidagilarni beradi:

CI/CD pipeline
Docker registry
Kubernetes cluster
Logging
Monitoring
Tracing
Secrets management
Deployment templates
Service discovery
Database migration flow
Alerting
Rollback mechanism

Yaxshi platform bo‘lsa, developer har safar noldan o‘ylamaydi.

Masalan:

Yangi Spring Boot service yaratildi
    ↓
Template ishlatildi
    ↓
CI/CD avtomatik bor
    ↓
Docker image chiqadi
    ↓
Kubernetesga deploy bo‘ladi
    ↓
Metrics/logs/tracing avtomatik ulanadi

3. DevOps Strategy nima?

DevOps strategy - development va operations orasidagi jarayonlarni avtomatlashtirish va standartlashtirish.

Asosiy maqsad:

Tezroq release
Kamroq xato
Oson rollback
Kuchli monitoring
Takrorlanadigan deployment
Manual ishlarni kamaytirish

Yomon holat:

SSH bilan serverga kirdik
git pull qildik
mvn package qildik
jarni restart qildik

Bu production uchun xavfli.

Yaxshi holat:

Git push
  ↓
CI pipeline
  ↓
Test + build + scan
  ↓
Docker image
  ↓
Deploy to staging
  ↓
Approval
  ↓
Deploy to production
  ↓
Monitoring + rollback

4. CI/CD Pipeline Design

CI nima?

CI - Continuous Integration

Ya’ni developer kod push qilganda avtomatik tekshiruvlar yuradi.

Git push
  ↓
Compile
  ↓
Unit tests
  ↓
Integration tests
  ↓
Static analysis
  ↓
Security scan
  ↓
Build artifact

CI maqsadi:

Xatoni production’da emas, Git push paytida topish.

CD nima?

CD ikki xil ma’noda ishlatiladi:

Ko‘p enterprise loyihalarda Continuous Delivery ishlatiladi:

Build avtomatik
Test avtomatik
Staging deploy avtomatik
Production deploy esa approval bilan

5. Spring Boot uchun CI/CD pipeline namunasi

Masalan Java/Spring Boot backend:

1. Checkout code
2. Setup JDK 21
3. Run unit tests
4. Run integration tests
5. Run Checkstyle/SpotBugs/Sonar
6. Build jar
7. Build Docker image
8. Push image to registry
9. Run database migration check
10. Deploy to staging
11. Smoke test
12. Manual approval
13. Deploy to production
14. Monitor metrics
15. Rollback if needed

GitHub Actions misoli

name: Java CI/CD

on:
  push:
    branches: [ "main" ]

jobs:
  build-test-package:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 21

      - name: Run tests
        run: ./mvnw test

      - name: Build jar
        run: ./mvnw clean package -DskipTests

      - name: Build Docker image
        run: docker build -t registry.example.com/sales-api:${{ github.sha }} .

      - name: Push Docker image
        run: docker push registry.example.com/sales-api:${{ github.sha }}

Bu hali minimal. Production’da secret management, image scan, staging/prod deploy, approval, rollback qo‘shiladi.

6. Pipeline’da nima bo‘lishi kerak?

Minimal pipeline

Compile
Unit test
Build artifact
Docker image
Deploy

Production-grade pipeline

Compile
Unit tests
Integration tests
Contract tests
Static code analysis
Dependency vulnerability scan
Container image scan
License scan
Build artifact
Docker image signing
Database migration validation
Deploy to staging
Smoke tests
Performance sanity checks
Manual approval
Deploy to production
Post-deploy monitoring
Rollback automation

7. Pipeline’dagi katta xatolar

1. Testlarsiz deploy

Kod build bo‘ldi = kod to‘g‘ri

Bu noto‘g‘ri. Build faqat syntax va dependency muammosini ushlaydi. Business buglarni test ushlaydi.

2. Manual deploy

Serverga SSH
jar copy
systemctl restart

Bu takrorlanmaydigan, xavfli va audit qilinmaydigan jarayon.

3. Secretlarni pipeline ichiga yozish

Yomon:

DB_PASSWORD: my-secret-password

Yaxshi:

GitHub Secrets
GitLab CI Variables
Vault
AWS Secrets Manager
Kubernetes Secrets

4. Rollback yo‘q

Deploy strategiyasida rollback bo‘lmasa, har release xavfli.

Arxitektor savoli:

"Agar release yomon chiqsa, necha daqiqada oldingi versiyaga qaytamiz?"

8. Docker Strategy

Java app production’da ko‘pincha Docker image sifatida chiqariladi.

Oddiy Dockerfile

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY target/app.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

Yaxshiroq multi-stage Dockerfile

FROM maven:3.9-eclipse-temurin-21 AS build

WORKDIR /app
COPY pom.xml .
COPY src ./src

RUN mvn clean package -DskipTests

FROM eclipse-temurin:21-jre

WORKDIR /app
COPY --from=build /app/target/*.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

Afzallik:

Build environment final image ichida qolmaydi
Image kichikroq bo‘ladi
Security yuzasi kamayadi

Java Docker image uchun e’tibor

9. Kubernetes Strategy

Kubernetes - containerlarni boshqarish platformasi.

Lekin arxitektor uchun muhim fikr:

Kubernetes scaling muammolarini hal qiladi, lekin yomon architecture’ni yaxshi qilib qo‘ymaydi.

Kubernetes asosiy obyektlari

Spring Boot Kubernetes deployment misoli

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sales-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sales-api
  template:
    metadata:
      labels:
        app: sales-api
    spec:
      containers:
        - name: sales-api
          image: registry.example.com/sales-api:1.0.0
          ports:
            - containerPort: 8080
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: prod
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080

10. Health Checks

Spring Boot’da Actuator bilan health endpointlar qilinadi.

Liveness probe

App tirikmi?
Deadlock/crash bo‘lsa restart qilish kerakmi?

Misol:

/actuator/health/liveness

Readiness probe

App traffic qabul qilishga tayyormi?
Database, cache, migration, startup tugadimi?

Misol:

/actuator/health/readiness

Farqi

Katta xato:

DB vaqtincha ishlamasa liveness failed qilib appni restart qilish

Bu restart loop keltirishi mumkin. DB muammosida odatda readiness false bo‘lishi kerak.

11. GitOps

GitOps nima?

GitOps - infrastructure va deployment holati Git repository’da saqlanadi.

Ya’ni Git - desired state.

Git repository:
  deployment.yaml
  service.yaml
  ingress.yaml
  config.yaml

Gitda nima yozilgan bo‘lsa, cluster ham shunga mos bo‘lishi kerak.

GitOps flow

Developer image chiqaradi
        ↓
Deployment repo’da image tag yangilanadi
        ↓
Pull request ochiladi
        ↓
Review/merge bo‘ladi
        ↓
ArgoCD/Flux clusterga sync qiladi
        ↓
Production holati Git bilan bir xil bo‘ladi

ArgoCD / Flux

GitOps afzalliklari

GitOps kamchiliklari

12. Infrastructure as Code - IaC

IaC nima?

Infrastructure as Code - server, network, database, bucket, firewall kabi infrani qo‘lda emas, kod orqali boshqarish.

Masalan Terraform bilan:

resource "aws_instance" "api_server" {
  ami           = "ami-123456"
  instance_type = "t3.medium"
}

Yoki cloud database:

resource "aws_db_instance" "postgres" {
  engine         = "postgres"
  instance_class = "db.t3.medium"
  allocated_storage = 100
}

Nega IaC kerak?

Yomon holat:

Admin panelga kirdik
server yaratdik
port ochdik
database qo‘shdik
hech kim aniq eslamaydi

Yaxshi holat:

Terraform apply
server yaratildi
database yaratildi
network sozlandi
hammasi Git’da

IaC afzalliklari

Terraform, Pulumi, Ansible farqi

13. Environment Strategy

Production’da odatda bir nechta environment bo‘ladi:

local
dev
test
staging
production

Har birining roli

Muhim qoida

Staging production’ga maksimal o‘xshash bo‘lishi kerak.

Agar staging boshqa config, boshqa DB version, boshqa infra bo‘lsa, production buglari oldindan chiqmaydi.

14. Configuration Strategy

Config kod ichida hardcode bo‘lmasligi kerak.

Yomon:

String dbUrl = "jdbc:postgresql://prod-db:5432/app";

Yaxshi:

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USER}
    password: ${DB_PASSWORD}

Config turlari

15. Secrets Management

Secretlar:

DB password
JWT signing key
API token
OAuth client secret
Private key
Encryption key

Bular:

Git repository’da
Docker image ichida
loglarda
plain config file’da

turmasligi kerak.

Yaxshi yechimlar

16. Deployment Strategies

1. Recreate deployment

Eski versiya o‘chadi, yangi versiya chiqadi.

v1 stop → v2 start

Kamchiligi:

Downtime bo‘lishi mumkin
Rollback sekinroq

Kichik loyiha uchun ba’zan yetadi.

2. Rolling deployment

Yangi versiya asta-sekin eski podlarni almashtiradi.

v1 v1 v1
v2 v1 v1
v2 v2 v1
v2 v2 v2

Afzallik:

Downtime kam
Kubernetes default yondashuv

Kamchilik:

Bir muddat v1 va v2 birga ishlaydi
Backward compatibility kerak

3. Blue-Green Deployment

Ikkita muhit bo‘ladi:

Blue  = hozirgi production
Green = yangi versiya

Flow:

Traffic Blue’da
Green deploy qilinadi
Green test qilinadi
Traffic Green’ga o‘tkaziladi
Muammo bo‘lsa Blue’ga qaytiladi

Blue-Green afzalliklari

Kamchiliklari

4. Canary Deployment

Canary - yangi versiyani oz foydalanuvchiga chiqarish.

95% traffic → v1
5% traffic  → v2

Agar metrikalar yaxshi bo‘lsa:

25% → 50% → 100%

Canary nima uchun yaxshi?

Canary uchun kerakli metrikalar

HTTP 5xx error rate
p95/p99 latency
CPU/memory
Business metric
Payment success rate
Login success rate
Queue lag

Canary faqat deploy qilish emas. Uni baholaydigan metrikalar bo‘lmasa, foydasi kamayadi.

17. Database Migration Strategy

Deployment’da eng xavfli joylardan biri - database migration.

Yomon holat

App v2 yangi column kutyapti
DB hali migration bo‘lmagan
Production crash

Yoki:

Migration eski columnni o‘chirib yubordi
App v1 hali shu columnni ishlatyapti

Safe migration: Expand-Contract

Masalan full_nameni first_name, last_namega almashtirish.

1. Yangi nullable columnlar qo‘shiladi
2. App v1 ham eski, ham yangi schema bilan ishlay oladi
3. App v2 yangi columnlarga yozishni boshlaydi
4. Eski data backfill qilinadi
5. Hamma instance v2 bo‘lgach, eski column deprecated
6. Keyingi release’da eski column o‘chiriladi

Flyway/Liquibase

Java/Spring loyihalarda ko‘p ishlatiladi:

Example Flyway:

db/migration
 ├── V1__init_schema.sql
 ├── V2__add_customer_phone.sql
 └── V3__create_order_index.sql

18. Multi-Region Deployment

Multi-region nima?

Application bir nechta geographic region’da ishlaydi.

Masalan:

Region A: Europe
Region B: Asia
Region C: US

Yoki O‘zbekiston uchun yaqinroq tasavvur:

Tashkent region
Frankfurt region
Singapore region

Nega kerak?

Active-Passive

Primary region active
Secondary region standby

Muammo bo‘lsa traffic secondary’ga o‘tadi.

Afzallik:

Oddiyroq
Data conflict kamroq

Kamchilik:

Failover vaqti bor
Secondary resurslar bekor turishi mumkin

Active-Active

Region A ham active
Region B ham active

Userlar yaqin regionga yo‘naltiriladi.

Afzallik:

Latency past
Availability yuqori

Kamchilik:

Data replication murakkab
Conflict resolution kerak
Cost yuqori
Architecture qiyin

Arxitektor xulosasi

Multi-region - katta reliability talablari uchun. Lekin database consistency, failover, cost va operational complexity keskin oshadi.

19. Observability Platform

Platform strategy ichida observability majburiy.

Production’da savollar:

App ishlayaptimi?
Qayerda sekinlashyapti?
Qaysi endpoint error beryapti?
Qaysi release’dan keyin xato oshdi?
Qaysi service bottleneck?
Database slow query bormi?
Queue lag oshdimi?

Uch asosiy ustun

Java/Spring stack

Logs:
Logback + JSON logs + ELK/Loki

Metrics:
Micrometer + Prometheus + Grafana

Tracing:
OpenTelemetry + Jaeger/Tempo/Zipkin

Health:
Spring Boot Actuator

20. Platform Security

Platform faqat deploy emas, security ham beradi.

Kerakli nazoratlar

Dependency vulnerability scanning
Container image scanning
Secrets scanning
SAST
DAST
RBAC
Network policies
TLS/mTLS
Audit logs
Least privilege access

Supply Chain Security

Bugungi production’da xavf faqat sizning kodingizda emas. Dependency, image, CI/CD, registry ham xavf manbasi.

Savollar:

Dependency ichida CVE bormi?
Docker image ishonchli registry’danmi?
Image kim tomonidan build qilingan?
Artifact imzolanganmi?
Pipeline’ga kim push qila oladi?
Production secretlarni kim ko‘ra oladi?

21. FinOps

FinOps nima?

FinOps - cloud/infrastructure xarajatlarini engineering va biznes bilan birga boshqarish.

Oddiy qilib:

System faqat ishlashi emas, iqtisodiy jihatdan ham oqilona bo‘lishi kerak.

Cloud cost qayerdan oshadi?

Keraksiz katta serverlar
Unused Kubernetes nodes
Ortiqcha logging
Juda katta retention
Read replica ishlatilmay turishi
Noto‘g‘ri autoscaling
Data transfer cost
Over-provisioned database
GPU/AI resource bekor turishi

FinOps savollari

Har service oyiga qancha turadi?
Eng qimmat 5 resource qaysi?
CPU/RAM utilization qanday?
Autoscaling to‘g‘ri ishlayaptimi?
Log retention qancha?
Development environment kechasi o‘chadimi?
Reserved instance kerakmi?
Storage lifecycle policy bormi?

Cost optimization misollar

22. Internal Developer Platform - IDP

Katta teamlarda platform team developerlar uchun self-service platform quradi.

Masalan developer shunday qilishi mumkin:

New service yaratish
Database so‘rash
Secret qo‘shish
Deploy qilish
Logs ko‘rish
Metrics ko‘rish
Rollback qilish

Bularning hammasi standart portal yoki CLI orqali bo‘ladi.

Misollar:

Backstage
Port
Humanitec
Internal CLI
Custom templates

IDP maqsadi

Developer tezroq ishlaydi
DevOps bottleneck kamayadi
Standartlar avtomatik qo‘llanadi
Security default bo‘ladi
Observability default bo‘ladi

23. Real loyiha uchun strategiya: Sales Agent / Supervisor

Ikki Android app va backend uchun amaliy platform strategy:

Android Apps
  - Supervisor
  - Sales Agent
        |
Nginx / Load Balancer
        |
Spring Boot Modular Monolith
        |
PostgreSQL
Redis
MinIO/S3
RabbitMQ

Boshlang‘ich bosqich

Kichik team uchun ortiqcha Kubernetes shart emas.

GitHub/GitLab
CI pipeline
Docker image
Docker Compose yoki bitta VPS
PostgreSQL managed yoki alohida server
Redis
Nginx reverse proxy
Basic monitoring
Daily backup

Minimal, lekin sog‘lom.

CI/CD flow

Push to main
  ↓
Unit tests
  ↓
Build jar
  ↓
Build Docker image
  ↓
Push registry
  ↓
Deploy staging
  ↓
Smoke test
  ↓
Manual approval
  ↓
Deploy production

Production server flow

Nginx
  ↓
sales-api container
  ↓
PostgreSQL
Redis
MinIO

Deploy script:

docker pull new-image
docker compose up -d
health check
agar fail bo‘lsa oldingi imagega rollback

Keyingi bosqich

Traffic oshsa:

Load Balancer
  ↓
sales-api-1
sales-api-2
sales-api-3
  ↓
PostgreSQL
Redis

Keyin:

Read replica
RabbitMQ workers
Central logging
Prometheus + Grafana
Blue-green deployment

Katta bosqich

Agar product jiddiy kattalashsa:

Kubernetes
GitOps with ArgoCD
Terraform
Managed PostgreSQL
Managed Redis
Object storage
OpenTelemetry
Canary deployments
Multi-region DR
FinOps dashboard

24. Platform maturity model

Level 1 - Manual

SSH deploy
Manual config
Backup noaniq
Monitoring yo‘q

Xavfli.

Level 2 - Basic Automation

CI build
Docker image
Simple deploy script
Basic logs
Manual rollback

Kichik project uchun start.

Level 3 - Production Ready

CI/CD
Automated tests
Staging
Health checks
Monitoring
Alerting
Backup restore test
Secret management
Rollback

Ko‘p real bizneslar uchun yaxshi.

Level 4 - Scalable Platform

Kubernetes
GitOps
IaC
Central observability
Canary/blue-green
Security scanning
Autoscaling
Cost monitoring

Katta team/system uchun.

Level 5 - Advanced Platform

Multi-region
Self-service platform
Policy as code
Automated incident response
Chaos testing
Advanced FinOps
Service mesh

Enterprise/high-scale daraja.

25. Arxitektor uchun checklist

CI/CD pipeline bormi?
Testlar deploydan oldin yuradimi?
Docker image reproduciblemi?
Secretlar Gitda emasmi?
Environmentlar aniq ajratilganmi?
Database migration safe usuldami?
Rollback strategy bormi?
Health check to‘g‘rimi?
Logs/metrics/traces bormi?
Alerting bormi?
Infrastructure kod bilan boshqariladimi?
Production access nazoratlimi?
Cloud xarajat o‘lchanyaptimi?
Backup restore test qilinganmi?

26. Katta xatolar

1. DevOps’ni faqat bitta odamga bog‘lab qo‘yish

Agar hamma deployni faqat bitta odam bilsa, bu risk.

To‘g‘ri yondashuv:

Deployment jarayoni dokumentlangan
Pipeline avtomatlashtirilgan
Rollback hammaga tushunarli
Access nazoratli

2. Kubernetesni juda erta tanlash

Kubernetes kuchli. Lekin kichik project uchun:

Kubernetes muammoni hal qilishdan ko‘ra ko‘proq muammo qo‘shishi mumkin

Avval oddiy Docker Compose + monitoring + backup ham yetarli bo‘lishi mumkin.

3. Monitoringni keyinga qoldirish

Production’da monitoring yo‘q bo‘lsa:

User aytmaguncha xatoni bilmaysiz

Bu professional yondashuv emas.

4. Rollbackni test qilmaslik

Rollback nazariyada bor, lekin hech qachon sinab ko‘rilmagan bo‘lsa, incident vaqtida ishlamasligi mumkin.

5. Secretlarni noto‘g‘ri saqlash

.env, Git, Telegram, Excel, serverdagi oddiy text file - bular production secret uchun xavfli.

6. Cloud costni nazorat qilmaslik

Kichik servis noto‘g‘ri log retention yoki katta DB instance sabab oyiga katta xarajat chiqarishi mumkin.

27. Arxitektor qaror tartibi

Platform va DevOps strategiyasini tanlashda tartib:

1. Team hajmini bahola
2. Product criticality bahola
3. Release frequency aniqlanadi
4. Availability talabi aniqlanadi
5. Compliance/security talabi aniqlanadi
6. Infra complexity tanlanadi
7. CI/CD minimal standartlari belgilanadi
8. Observability default qilinadi
9. Rollback va backup majburiy qilinadi
10. Cost monitoring qo‘shiladi

Arxitektor darajasida maqsad:

Eng zamonaviy tool ishlatish emas
Team ko‘tara oladigan, xavfsiz, takrorlanadigan delivery system qurish

28. Yakuniy formula

Platform & DevOps Strategy =
CI/CD
+ Containerization
+ Environment Management
+ Secrets
+ Infrastructure as Code
+ GitOps
+ Deployment Strategy
+ Observability
+ Security
+ FinOps

Eng muhim xulosa:

Yaxshi platform developerga tezlik beradi, production’ga xavfsizlik beradi, biznesga esa barqarorlik va xarajat nazoratini beradi.

Java/Spring Boot loyihalar uchun amaliy start:

GitHub/GitLab CI
+ Java 21 build
+ Unit/integration tests
+ Docker image
+ Flyway/Liquibase migration
+ Staging environment
+ Manual production approval
+ Health checks
+ Prometheus/Grafana
+ Central logs
+ Backup/restore test
+ Simple rollback

Arxitektor sifatida eng yaxshi savol:

"Biz kodni production’ga tez, xavfsiz, takrorlanadigan va rollback qilinadigan qilib chiqaryapmizmi?"