The product is deployed as an HA cluster across 20+ servers via Docker Compose and Ansible; the strategic goal is a move to Kubernetes. The microservice codebase was built for Compose: networking through an external Docker network, DNS via the embedded resolver, database and broker configs defaulting to 127.0.0.1/localhost. In Kubernetes these assumptions silently break on deploy — I needed to understand what blocks the migration and estimate the scope of changes.

• ran a static analysis of 15 repositories: Go services, a PHP monolith, HAProxy/Nginx configs, integration services
• categorized findings by criticality: migration-critical (block startup) vs. low-priority (dev/CI/test)
• found 12+ spots with hardcoded DNS/IP assumptions, 7+ loopback defaults for databases and brokers, Docker-specific resolvers in proxies and a healthcheck bound to localhost instead of the pod IP
• gave a concrete recommendation for each finding: replace defaults with mandatory env variables that fail fast at startup, move the Docker network to K8s Services, extract hardcoded gRPC addresses into config
• flagged a separate class of problems: a service with a peer's address baked into compiled code — needs refactoring, not a config change

The product ships to customers with built-in S3 storage — one instance per installation. Production volume: ~8 TiB, 1.8M objects; the storage is used by the main application, several Go services, an Ansible playbook, DB backup tools, a container registry and a corporate messenger. The current S3 backend changed the licensing policy of its OSS edition (part of the functionality moved to Enterprise, the console was removed from community) — shipping it on-prem to customers is legally risky, all the more so given import-substitution requirements.

• built an S3 requirements matrix — 20+ criteria: Data/Control Plane, Event Notifications → AMQP, Bucket Lifecycle, IAM Bucket Policy, SSE-KMS, Prometheus metrics, path-style, Sigv4, compatibility with three S3 clients and the backup tooling
• compared three options: status quo (100% of the matrix, but a licensing blocker); option A — rejected (no Event Notifications over AMQP, no SSE-KMS, limited Lifecycle, AGPL); SeaweedFS (Apache 2.0, ~95% of the matrix, AMQP → RabbitMQ, compatible with all clients)
• chose SeaweedFS — the only option with an OSS license free of feature-gating and suitable for shipping to customers
• designed a test plan: 15 Spike cases (Go/No-Go) + 15 PoC/prod — multipart upload >10 GB, presigned URLs with header overrides, Bucket Lifecycle, SSE-KMS via an external KMS, a 30-min load run to compare p99 latency
• analyzed storage schemes: replication (×2 overhead, from 2 nodes) vs. Erasure Coding 10+4 (×1.4 overhead, from 14 nodes) — with a recommendation per data group
• prepared a 10-step production migration plan: sync with checksum verification, a read-only cutover window, smoke checks, a control operation period

The product runs on several Linux distributions; enterprise customers in Russia request support for domestic OSes. Adding a new OS was informal: an engineer would add the distribution to the allowed list and consider it done. Without a clear gate an OS could enter the documentation without a full verification cycle (load testing skipped, distributed/offline modes unchecked) — the risk being that a customer gets an OS on the supported list and hits an incompatibility at deployment.

• designed a process with 3 OS statuses (Supported / Deprecated / Removed) and a 4-stage SDLC checklist: Assessment → In Progress (Done) → Testing → Released
• defined the task structure: Feature → User Stories per team → Subtasks for each type of work (specification, test plan, load-test plan, environments, documentation)
• set requirements for the test environments: matching OS/Docker/Compose versions, installed and configured automatically via a pipeline/ChatOps before work starts
• fixed a mandatory entry gate for work: OS Ansible facts, Docker/containerd/Compose details, load-test scope (agreed with the Scaling Team), known risks
• specified the final artifacts: MR/branch, CI jobs (pre-check/deploy/post-check), smoke/E2E, k6 artifacts (runtime.zip, JSON, xlsx, HTML, Grafana), Scaling Team verdict, known limitations
• made load testing a mandatory gate for Supported status and defined re-verification triggers: a change of OS major/minor version, Docker pins, repository, kernel/cgroup defaults, CA/GPG/proxy, key components or the base k6 scenario

The product uses external S3 storage for release artifacts, DB backups, CI artifacts and auxiliary services. The exact volume wasn't tracked — capacity planning was done roughly.

• ran a read-only inventory of 18 buckets without modifying data
• recorded volume, object count, last-write date and content type for each bucket
• established that ~75% of the volume (≥300 GB) was release artifacts accumulated since 2022 with no retention policy
• identified several backup repositories with no retention limits — uncontrolled volume growth
• found buckets with no writes for 1.5–4 years totaling ≥19 GB (test-environment backups, registry images, repository mirrors) and duplicate rebuilds of a single release minor
• prepared prioritized recommendations: retention for releases, forget --prune (restic), wal-g delete retain, lifecycle expiration for temporary artifacts, per-bucket monitoring

The status of a large share of work had to be checked with the people doing it. Operational and project tasks were mixed, engineers chose their next task themselves, and management had no single set of metrics for queues, load and cycle time.

• split operational work in ITSM from project work in SDLC
• created separate queues for incidents, requests, problems, changes and unassigned tasks
• introduced priority-based queue processing instead of engineers self-selecting tasks
• set requirements for keeping statuses and comments current on long-running tasks
• rolled out metrics for queue age and size, staff load, effort and cycle time
• tied operational metrics to the team's monthly KPI

People were grouped mostly by historically formed technology specializations. Areas of responsibility overlapped, the manager remained the entry point for a large number of operational questions, and context switching hurt productivity.

• split the department into three tracks: DevOps, SRE and Managed Apps
• appointed leads and assigned services and areas of responsibility to the teams
• built a roles-and-FTE model for capacity planning
• introduced a quarterly performance-review cycle and regular one-to-ones
• developed a competency matrix for the DevOps track
• built mentoring, knowledge sharing and process improvement into the incentive system

Existing service descriptions didn't always make it possible to pin down the scope of work, the limits and the responsibilities of client and provider. That created risks at presale, at service activation, in operation and in later billing.

Productized four core managed services — Managed Monitoring, Managed Logging, Software Backup and Managed OS. For the portfolio I prepared:

• unified service descriptions in Russian and English
• SLAs and responsibility matrices
• activation requirements and questionnaires
• lists of typical requests
• rules for changing parameters and deactivating services
• GPLs and billing units
• presale calculators
• XS–XL engineer-hour packages with progressive discounts

Data on revenue, billed services, effort and team cost lived in different systems and reports. It was hard to tell the profitability of a specific client or service, or to separate billable activity from operational losses.

• consolidated data from billing, 1C, ITSM and timesheets
• built the department's first P&L model
• introduced plan-vs-actual for revenue and costs
• started measuring gross margin by service
• added revenue and profit per employee
• automated part of the monthly billing reports
• set up regular effort analysis by client and service

At a large product client the actual volume of DevOps work and the payment model in use had drifted apart. Development, maintenance, consulting and infrastructure support were all mixed within a single contract.

• audited tasks, effort and infrastructure objects
• split the work into Build and Support
• calculated the required team composition and FTE shares
• developed T&M and package-pricing models
• set separate rates for junior, middle, senior and architect roles
• standardized monthly reporting for DevOps and Managed IT
• prepared a service matrix and a cost calculator for the supported infrastructure

Health models for some services were out of date, some alerts created extra noise, and knowledge about the architecture and failure scenarios stayed with individual engineers. After a major incident with the DNS service it turned out that part of the PostgreSQL/Patroni configuration had been applied manually and wasn't stored in the distributed configuration store. During a cluster switchover this broke replication.

• organized an update of service health models
• introduced a dedicated health model and alerting for the DNS service
• tuned alerts for PostgreSQL and PHP-FPM
• formalized the timeline of the major incident and its root cause
• coordinated communication between engineers, adjacent teams and the service center
• moved corrective actions from manual operations into cluster configuration and automated deployment
• captured the changes in DCS/etcd and infrastructure playbooks

The client needed not a catalog-standard monitoring service but a custom one for its critical services — with a guaranteed incident response in 24×7 mode. The portfolio had no ready product for that response level, and one-off agreements gave neither predictable quality nor clear economics.

Took the service through the full lifecycle — from requirements to operation and billing:

• gathered requirements, monitored objects and critical scenarios, agreed thresholds and priorities
• designed and built custom monitoring and alerting for the client's services
• set a 7-minute response SLA in 24×7 mode with on-call, routing and escalations
• packaged the service commercially: scope of work, billing units, SLA matrix and calculator
• ran activation, handover to operations and regular reporting