{"id":4483,"date":"2026-01-27T21:08:25","date_gmt":"2026-01-27T15:38:25","guid":{"rendered":"https:\/\/www.itsupportwale.com\/blog\/10-devops-best-practices-for-faster-software-delivery\/"},"modified":"2026-01-27T21:08:25","modified_gmt":"2026-01-27T15:38:25","slug":"10-devops-best-practices-for-faster-software-delivery","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/10-devops-best-practices-for-faster-software-delivery\/","title":{"rendered":"10 DevOps Best Practices for Faster Software Delivery"},"content":{"rendered":"

text
\n$ kubectl get pods -n prod
\nNAME READY STATUS RESTARTS AGE
\napi-gateway-v2-7f8d9b4c-xhq2z 0\/1 CrashLoopBackOff 42 (3m ago) 14h
\norder-processor-66d5f4e3-99abc 0\/1 OOMKilled 12 (1m ago) 14h
\npayment-service-55c2a1b0-zxy98 1\/1 Running 0 14h
\nmarketing-tracker-88f123a4-bbbbb 1\/1 Running 0 14h<\/p>\n

$ kubectl logs -f api-gateway-v2-7f8d9b4c-xhq2z –previous
\n{“level”:”fatal”,”ts”:1715432100.123,”caller”:”main.go:45″,”msg”:”failed to connect to redis”,”error”:”dial tcp 10.96.0.15:6379: i\/o timeout”}
\n{“level”:”info”,”ts”:1715432105.456,”msg”:”Attempting reconnection… (Attempt 43)”}
\npanic: runtime error: invalid memory address or nil pointer dereference
\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8a2f31]<\/p>\n

$ terraform plan
\n\u2577
\n\u2502 Error: Error acquiring the state lock
\n\u2502
\n\u2502 Error message: conditional check failed
\n\u2502 Lock Info:
\n\u2502 ID: 6e2f1a3b-8c9d-4e5f-a1b2-c3d4e5f6a7b8
\n\u2502 Path: prod-infrastructure\/terraform.tfstate
\n\u2502 Operation: OperationTypePlan
\n\u2502 Who: jenkins-worker-04@ip-10-0-45-12
\n\u2502 Version: 1.5.7
\n\u2502 Created: 2024-05-11 02:14:05.123456 +0000 UTC
\n\u2502 Info:
\n\u2575<\/p>\n

The sun is coming up. Or maybe it\u2019s going down. I can\u2019t tell. The blue light from my triple-monitor setup has burned a permanent rectangular ghost into my retinas. My hands smell like stale coffee and the cheap mechanical keyboard grease that accumulates after 72 hours of frantic typing. \n\nThree days ago, some "Growth Hacker" in a slim-fit suit decided we needed a "Flash Loyalty Reward Event" to coincide with a celebrity tweet. They didn't tell Engineering. They didn't tell SRE. They just pushed the "Go" button on a campaign that hit forty million users simultaneously. \n\nAnd now, here I am. Staring at a terminal that\u2019s screaming at me because our "elastic" infrastructure decided to snap like a dry twig. If this is what you call **devops best**, I\u2019m moving to a farm. I\u2019m done. I\u2019m writing this because if I don\u2019t, the next person who inherits this cluster will probably jump off the roof.\n\n## The YAML Hell We Built for Ourselves\n\nWe\u2019re running Kubernetes v1.29. It\u2019s supposed to be the pinnacle of container orchestration. Instead, it\u2019s a 1.5-million-line YAML suicide note. We\u2019ve abstracted the infrastructure so far away from the hardware that nobody knows where the packets actually go anymore. \n\nWhen the marketing spike hit, the `api-gateway` started failing its liveness probes. Why? Because the "DevOps Architects" decided that every pod needed fifteen sidecars for "observability," "security," and "service mesh magic." By the time a request actually hits the application code, it\u2019s traveled through three proxies, been encrypted and decrypted four times, and had its headers bloated by 4KB of tracing metadata.\n\nThe `kubelet` on worker node `ip-10-0-112-4` decided it had enough. It went `NotReady`. Why? Because the `conntrack` table overflowed. We\u2019re pushing so many tiny, useless UDP packets for "telemetry" that the kernel literally forgot how to talk to the network.\n\nLook at this absolute garbage. This is the "standard" deployment manifest for the service that died first.\n\n```yaml\n# This is the manifest that killed the cluster.\n# "Optimized" by a consultant who left six months ago.\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: order-processor\nspec:\n  replicas: 50 # Marketing said we'd need "scale"\n  template:\n    spec:\n      containers:\n      - name: app\n        image: internal-repo\/order-processor:latest # Because versioning is for cowards\n        resources:\n          limits:\n            cpu: "200m" # Not enough to actually process an order\n            memory: "256Mi"\n          requests:\n            cpu: "100m"\n            memory: "128Mi"\n        livenessProbe:\n          httpGet:\n            path: \/healthz\n            port: 8080\n          initialDelaySeconds: 3\n          periodSeconds: 5 # Let's hammer the app while it's struggling to boot\n      - name: telemetry-sidecar\n        image: telemetry-vendor\/agent:v4.2.1\n        resources:\n          limits:\n            cpu: "500m" # The sidecar gets more CPU than the app. Brilliant.\n            memory: "512Mi"\n<\/code><\/pre>\n
I spent four hours yesterday just trying to figure out why the order-processor<\/code> was OOMKilled. It turns out the “telemetry-sidecar” has a memory leak that triggers whenever the network latency exceeds 50ms. And since the network was saturated by the marketing spike, the sidecar ate all the node’s memory, the kubelet<\/code> panicked, and the OOM Killer started executing random pods like a firing squad.<\/p>\n
\n
Table of Contents<\/p>\n