From DevSecOps to Operational Resilience: 26 Engineering Improvements Across Cloud, Kubernetes and ML Infrastructure

*From Security Scanning to Operational Resilience: Engineering Improvements Across DevSecOps, Cloud and ML Infrastructure *

Lessons from integrating security into CI/CD, strengthening observability, automating recovery, modernising API gateways and improving production operations.

Modern platform engineering is not just about deploying applications faster. It is about building secure, reliable, recoverable and maintainable systems while reducing manual operational effort.

In a multi-cloud environment supporting pharmaceutical SaaS applications, API platforms, Kubernetes clusters and machine learning services, operational excellence requires a combination of DevSecOps, observability, automation, capacity management and disciplined change control.

Over time, I have worked on a series of engineering improvements across CI/CD pipelines, on-premises infrastructure, Azure Kubernetes Service (AKS), Oracle Cloud Infrastructure (OCI), API gateways, databases, monitoring platforms and ML workloads.

These improvements share a common objective: shift operational practices from reactive troubleshooting towards proactive controls, repeatable automation and evidence-based engineering decisions.

This article explores the key improvements, the engineering considerations behind them and the operational value they bring.

1. Integrating Gitleaks with CI/CD: Bringing Secret Detection into the Development Workflow

Security vulnerabilities can enter a production environment long before deployment. Hard-coded credentials, API tokens, passwords and private keys committed to source control are examples of risks that should be detected as early as possible.

To address this, I integrated Gitleaks into the CI/CD workflow to identify potential secrets in source code and related repository content.

Why this matters

When credentials are committed to a repository, the risk extends beyond the immediate application. Credentials may be copied into build logs, cached artifacts, cloned repositories or downstream environments. Removing the secret from the latest commit does not necessarily remove it from the repository's history or eliminate the need to rotate it.

Engineering approach

The integration introduces secret scanning into the software delivery process, allowing findings to be identified closer to the point where code changes are introduced.

A mature implementation should include:

• Scanning code changes and, where appropriate, repository history.
• Reviewing findings to distinguish genuine secrets from false positives.
• Assigning ownership for remediation.
• Rotating exposed credentials rather than relying solely on deleting them from source code.
• Defining severity-based handling and exception procedures.
• Retaining scan results and remediation evidence according to policy.

The next level of maturity is to enforce pipeline failure for confirmed policy violations, subject to an agreed exception process. Detection and build-blocking enforcement are separate controls and should be implemented and verified independently.

Operational value: Earlier detection of credential exposure, improved security awareness in development workflows and a foundation for policy-driven DevSecOps.

2. Strengthening Security Visibility with Wazuh Across On-Premises Servers

Security controls are more effective when infrastructure events can be observed centrally.

I worked on installing Wazuh across on-premises servers to improve security monitoring and centralise visibility into relevant host events.

Key considerations

A successful deployment involves more than installing an agent. It requires attention to:

• Agent connectivity and health.
• Collection of relevant security events.
• Alert rules and severity classification.
• Investigation and escalation procedures.
• Ownership of findings and remediation.
• Monitoring of agent coverage and reporting gaps.

The operational objective is to make security events visible to the appropriate teams and provide a consistent basis for investigation.

A useful follow-up measure is coverage: the number of in-scope servers reporting successfully compared with the total number of servers that should be monitored. Additional measures can include alert investigation time and the age of unresolved high-priority findings.

Operational value: Improved security visibility across the on-premises server estate and a stronger basis for operational risk monitoring.

3. Evaluating Root-Access Changes Through a Proof of Concept

Privileged access is one of the most sensitive areas of infrastructure administration. Excessive or poorly controlled root access can increase the impact of accidental changes, compromised credentials and unauthorised activity.

I worked on a proof of concept for changing root-access practices, with broader rollout identified as a subsequent step.

A controlled approach to privileged access should consider:

• Whether administrative access can be performed through named accounts and approved privilege elevation.
• Authentication and authorisation requirements.
• Audit logging for privileged commands and sessions.
• Emergency access procedures.
• Service dependencies that may require special treatment.
• A tested rollback and recovery approach.

A proof of concept should validate compatibility with existing administration procedures before wider deployment. Production rollout should include a staged migration, clear ownership, exception handling and a method to recover access if the new controls fail.

Operational value: A structured path towards stronger privileged-access governance without introducing avoidable operational disruption.

4. Upgrading Trivy to Improve Vulnerability-Scanning Currency

Container and infrastructure security scanning must evolve alongside the tools, libraries and vulnerabilities they are intended to detect.

I upgraded Trivy from version 0.58.1 to 0.64.1 as part of maintaining the security tooling used in the engineering environment.

Tool upgrades are an important operational activity, but the upgrade alone does not establish that vulnerabilities have been eliminated.

A sound upgrade process should include:

1. Reviewing release notes and compatibility considerations.
2. Testing the new version against representative images and repositories.
3. Validating vulnerability database access and scan output.
4. Comparing findings and investigating material differences.
5. Confirming that CI/CD integrations continue to operate correctly.
6. Documenting the deployed version and the upgrade outcome.

The broader objective is to ensure that scanning remains a dependable part of the delivery process and that findings can be prioritised and remediated.

Operational value: Updated vulnerability-scanning tooling and a stronger foundation for maintaining consistent container security checks.

5. Resolving Certificate Trust Issues Between On-Premises Containers and OCI OpenSearch

Secure communication between distributed systems depends on correct certificate trust configuration.

An SSL connectivity issue was encountered when on-premises containers communicated with OCI OpenSearch. The issue was resolved by adding the required CA certificate to the operating system on the OCI server.

This illustrates an important troubleshooting principle: TLS failures are not always caused by application code or network connectivity. They can arise from certificate chains, trust stores, hostname verification, certificate expiry or configuration differences between environments.

A systematic investigation should validate:

• The certificate presented by the remote endpoint.
• The certificate chain and relevant CA certificates.
• The trust store used by the client process.
• Hostname and certificate validity checks.
• Certificate expiry and renewal procedures.
• Connectivity and TLS negotiation using approved diagnostic tools.

The durable fix should also be documented and incorporated into configuration management where appropriate, rather than relying on manual changes that may be lost during rebuilds.

Operational value: Restored secure connectivity and a clearer understanding of certificate trust dependencies between environments.

6. Improving Cloud Hygiene by Removing Unused Route 53 Records

Cloud resources and DNS records can remain after services are migrated, retired or replaced. Unused records create unnecessary configuration complexity and may introduce security, ownership or troubleshooting risks.

I removed unused Route 53 URLs after identifying records that were no longer required.

DNS cleanup should be performed carefully because a record that appears unused may still support a legacy integration, scheduled job, external client or certificate-validation workflow.

A controlled cleanup process should include:

• Identifying the record owner and associated service.
• Reviewing traffic and dependency evidence where available.
• Confirming that the target service has been decommissioned or migrated.
• Checking certificate, redirect and integration dependencies.
• Recording the change and retaining a recovery path where appropriate.
• Validating service behaviour after removal.

Operational value: Reduced DNS clutter and improved configuration maintainability, provided that dependency checks and post-change validation are completed.

7. API Gateway Modernisation: WSO2, Kong, Azure API Management and OCI API Gateway

API gateways are critical infrastructure components because they sit on the path between clients and backend services. Their configuration, availability and migration strategy can directly affect application connectivity.

My API gateway improvement work included WSO2-to-Kong migration activities, Kong failover-related implementation, API migration from Azure API Management to OCI API Gateway and work involving migration of services to Standard API Manager from Basic SKU.

Addressing OCI API Gateway service limits

During the migration to OCI API Gateway, a service configuration constraint involving the limit of 50 APIs per service required attention. The engineering team reduced the number of APIs configured per service to remain below that limit.

This is an example of adapting API architecture to the constraints of the target platform instead of treating migration as a direct copy of the source configuration.

Resolving Jasper API compatibility issues

Jasper APIs that were invoked from Azure did not function as expected after the move to OCI API Gateway. OCI Functions were used to address the integration issue.

The broader engineering lesson is that API migration requires functional validation, not just successful deployment. Differences in request handling, authentication, integration behaviour, routing and platform capabilities can affect API compatibility.

Reliability and failover

Kong failover implementation and related proof-of-concept activities were also part of the improvement work.

A robust failover implementation should verify:

• Health detection and failure thresholds.
• Routing to the correct healthy endpoint.
• Connection and session behaviour.
• Authentication, rate limiting and TLS configuration.
• Recovery when the original node becomes healthy again.
• Logging, alerting and operational ownership.

A failover design should be tested under controlled failure scenarios before it is treated as production-ready.

Operational value: Improved migration readiness, more deliberate gateway architecture and a structured approach to API availability and failover.

8. Automating Kong API Manager Administration

Manual API management can become difficult to maintain as the number of services, configurations and environments grows.

I developed an automated script for managing Kong API Manager activities.

Automation is especially useful for repeatable administrative tasks when it reduces configuration inconsistency and improves execution speed. However, API-management automation must also protect against accidental changes to routes, credentials, upstream services or access policies.

A reliable automation workflow should include:

• Validated inputs and environment selection.
• Authentication using appropriately protected credentials.
• Pre-change checks and configuration validation.
• Logging of actions and results.
• Error handling and safe failure behaviour.
• Change traceability and controlled permissions.
• Post-change verification.

Operational value: A foundation for more repeatable API administration and reduced reliance on manual configuration steps.

9. Building a More Reliable Backup and Recovery Practice

Backups are only useful when they are available, consistent and recoverable when required.

I implemented automated backup processes across several infrastructure and data platforms, including:

• Zabbix
• Kong
• Grafana
• Prometheus
• Weaviate
• Dgraph
• Legal-Elastic
• Redis
• PostgreSQL
• MLflow

Additional work included automated PostgreSQL database backups and the use of an NFS server on separate box to receive backups from the five-node Elasticsearch cluster on Master Node.

The objective was to make backup execution more repeatable and reduce dependence on manual intervention.

Backup automation is only the first step

A production-ready backup process should also monitor completion, validate backup integrity, control access, manage retention and verify that the recovery process works.

Key questions include:

• Did the backup complete?
• Does the backup contain the expected data?
• Is it protected from accidental or unauthorised deletion?
• Can it be restored independently of the production failure?
• Can the service be recovered within its agreed RTO?
• Is the amount of data lost within the agreed RPO?

These checks are essential because a successful backup job is not proof of recoverability.

Operational value: More repeatable backup execution across a diverse technology stack and a foundation for better recovery readiness.

10. Restoring Legal-Elastic and Weaviate Data

Backup processes become more meaningful when recovery is demonstrated.

As part of the operational work, I restored Legal-Elastic on Backup Server and restored Weaviate data on Master node.

These activities provided practical experience with data restoration and the operational dependencies involved in bringing data services back into service.

A restoration procedure should validate more than whether a process starts. Depending on the platform, verification may include:

• Database or index health.
• Expected collections, indices or records.
• Data consistency and application connectivity.
• Authentication and access controls.
• Application-level queries.
• Evidence that the restored service is fit for its intended use.

The next maturity step is to formalise recurring restore tests, record the duration and results, and compare them against recovery objectives.

Operational value: Demonstrated restoration capability for the specific systems involved and a basis for improving recovery procedures.

11. Recovering a 2 TB Disk Snapshot for a UAT Environment

A disk recovery activity involved using a 2 TB disk snapshot to create and mount a disk on the UAT virtual machine on Azure. The restored data was checked with Ayan, after which the original 2 TB disk was depleted and decommissioned.

This activity highlights the importance of managing the complete lifecycle of recovered storage—not just creating the disk.

A controlled process should confirm:

1. The correct snapshot and recovery point were selected.
2. The restored disk was attached and mounted safely.
3. The expected data was available and validated by the relevant owner.
4. The UAT environment could access the required data.
5. The original disk was no longer required before decommissioning.
6. The storage change and decommissioning were documented.

The principle is simple: validate the recovery target and data before retiring the original resource.

Operational value: Recovered storage and validated data availability for the UAT environment, followed by the removal of the original disk after confirmation.

12. Expanding Elasticsearch Cluster Capacity

I added Node 4 and Node 5 as Elasticsearch nodes to an existing cluster having 3 nodes.

Adding nodes can increase available capacity and provide more flexibility in distributing data and workload. However, node addition must be accompanied by cluster-health and capacity validation.

Important checks include:

• Cluster health before and after the change.
• Node discovery and membership.
• Shard allocation and rebalancing.
• Disk utilisation and storage watermarks.
• Heap utilisation, CPU and query latency.
• Replication and recovery activity.
• Any application impact during rebalancing.

Operational value: Expanded the cluster's node footprint, creating additional capacity potential. The actual performance or capacity improvement should be established from before-and-after metrics.

13. Resource Optimisation Through Pod and Docker Profiling

Infrastructure capacity decisions should be based on observed workloads rather than assumptions.

I carried out proof-of-concept work for pod profiling and then profiled pods across Development, QA, Sales and UAT Kubernetes clusters. I also performed Docker profiling for ML services.

Profiling helps identify:

• CPU and memory utilisation patterns.
• Workloads with excessive or insufficient resource requests.
• Potential memory leaks or unexpected growth.
• Containers that frequently restart or encounter OOM termination.
• Opportunities for resource right-sizing.
• Workloads that may benefit from isolation or separate scaling policies.

This is particularly important for ML workloads, where resource demand can vary significantly between model types and execution patterns.

Profiling should cover normal usage as well as peak periods. Reducing resource allocations based only on average usage can introduce instability during traffic spikes or concurrent workloads.

Operational value: Better evidence for capacity planning and resource optimisation across Kubernetes and containerised ML services.

14. ML Service Rationalisation and Ollama Configuration

I worked on ML service deprecation activities, Ollama configuration changes for ML services and Ollama model availability on GPU hosts.

These activities relate to managing an evolving ML infrastructure footprint and aligning deployed services and models with operational requirements.

For service deprecation, a controlled process should verify service ownership, consumer dependencies, traffic usage, replacement availability and rollback requirements before a service is retired.

For model and GPU-host configuration, important operational considerations include:

• GPU and memory utilisation.
• Model compatibility and loading behaviour.
• Concurrent request capacity.
• Model-serving latency and error rates.
• Process health and recovery.
• Version consistency and configuration management.

The objective is to maintain a service footprint that is operationally supportable while ensuring that active workloads continue to meet their functional requirements.

Operational value: Improved management of ML service and model configurations. Quantified resource savings or inference-performance improvements should be reported only after measurement.

15. Automating ML Service Deployment

I completed proof-of-concept work for ML service deployment automation, with broader automation across all ML services identified as a next step.

ML deployment automation can reduce manual configuration, improve repeatability and help maintain consistency across multiple environments.

A mature workflow should cover:

1. Versioned deployment configuration.
2. Validation of required secrets and environment variables.
3. Image and dependency checks.
4. Resource configuration and health probes.
5. Deployment execution with appropriate permissions.
6. Post-deployment smoke tests and service validation.
7. Failure handling and rollback.
8. Audit-friendly records of what was deployed and when.

The important distinction is between a working proof of concept and a fully operationalised deployment framework. Broader rollout should include testing, documentation, ownership and support procedures.

Operational value: A foundation for consistent ML deployment and a path towards reducing manual deployment effort.

16. Operational Resilience Through Swap Configuration

Swap configuration was standardised based on available host memory:

• Hosts with 8 GB RAM: 4 GB swap.
• Hosts with 16 GB RAM: 8 GB swap.
• Hosts with 32 GB RAM: 8 GB swap.

Swap can provide a buffer during memory pressure, but it is not a replacement for adequate physical memory. Excessive swapping can also degrade application performance, especially for latency-sensitive services.

A production implementation should monitor swap usage, memory pressure, OOM events and application response times. It should also consider workload characteristics and the performance implications of swapping.

Operational value: More consistent swap configuration across the specified host sizes, with the actual reliability benefit dependent on workload behaviour and monitoring evidence.

17. Safer Service Isolation and Environment Segregation

I worked on separating the vigilance data service by deploying vigilance-qa in the QA cluster and vigilance-prod in the Prod cluster. I also worked on service-ner environment segregation.

Separating services by environment can improve operational isolation, reduce the risk of accidental cross-environment interaction and make deployment ownership clearer.

However, segregation requires more than separate deployment names. It should also consider:

• Namespace and cluster boundaries.
• Service accounts and permissions.
• Network access.
• Environment-specific secrets and configuration.
• Database and external-service connectivity.
• Monitoring, logging and alert routing.
• Deployment and rollback procedures.

Operational value: Clearer environment separation and a more controlled foundation for managing service configurations across QA and Sales.

18. Improving Kubernetes Deployment Safety with Health Probes and Strategies

I updated deployment.yaml configurations with liveness probes, readiness probes and deployment strategies for backend services across Development, QA and Prod environments.

These controls address different aspects of application availability.

• Readiness probes help prevent traffic from reaching pods that are not ready to serve requests.
• Liveness probes help detect applications that need to be restarted.
• Deployment strategies control how application versions are rolled out and how old and new instances coexist during a change.

Correct configuration is critical. A liveness probe that is too aggressive can cause restart loops, while an inadequate readiness probe can expose users to an application that has started but is not ready.

Deployment validation should cover normal startup, slow startup, dependency failures, rolling updates and rollback scenarios.

Operational value: Stronger deployment-level health controls and a more structured approach to managing backend service updates.

19. Liquibase CI/CD for Database Changes

Database changes require a controlled approach because schema modifications can affect application compatibility, data integrity and recovery.

I worked on Liquibase CI/CD for database delivery.

A well-designed database deployment pipeline should include:

• Version-controlled migration scripts.
• Review and approval of changes.
• Validation against the target database.
• Controlled execution in the appropriate environment.
• Compatibility checks between application and schema versions.
• Verification after migration.
• A documented recovery or forward-fix strategy.

Database rollback requires special consideration. Not every schema or data transformation can be safely reversed, so the recovery strategy must be designed for the specific change.

Operational value: A foundation for repeatable, traceable database changes and closer integration between application and database delivery processes.

20. Jenkins Upgrade and Deployment Hygiene

I upgraded Jenkins from version 2.479.2 to 2.504.3.

CI/CD infrastructure is itself a critical production dependency. An upgrade should therefore include plugin compatibility checks, configuration and job validation, backup verification, access-control review and post-upgrade testing.

I also updated deployment scripts to automatically delete TAR files from 52 hosts after deployment, and backed up deployment scripts from those hosts to Bitbucket.

These activities address two operational concerns: managing deployment artefacts after use and retaining version-controlled copies of operational scripts.

A strong implementation should verify that:

• The artefact is no longer needed by the running application or rollback process.
• Cleanup only targets the intended files and directories.
• Script failures are logged and surfaced.
• The deployment outcome is not reported as successful when required cleanup or validation fails.
• The version-controlled script is accessible to authorised maintainers.

Operational value: More consistent deployment cleanup and improved version-control coverage for deployment scripts.

21. Standardising the Linux Operating-System Baseline

I worked on upgrading Ubuntu from version 20.04 to 22.04.

Operating-system upgrades require a balance between security maintenance, application compatibility and service availability. A safe upgrade process should include dependency assessment, testing, backup validation, change approval, rollback planning and post-upgrade health checks.

For production systems, I would also verify monitoring-agent compatibility, service startup behaviour, network configuration, scheduled jobs and application dependencies.

Operational value: Progress towards a more current operating-system baseline for the systems included in the upgrade.

22. Managing ML Automation with Locking Controls

I worked on a lock script for ML automation.

Concurrent automation can create conflicts when multiple jobs attempt to modify the same resource, deploy the same service or run an operation that should only have one active execution.

Locking controls can help prevent duplicate execution, but they must handle stale locks, abnormal termination, ownership and safe release.

A production-ready implementation should define:

• What resource is protected.
• How lock ownership is established.
• How stale locks are detected and recovered.
• How concurrent execution attempts are handled.
• What happens when a job fails midway.
• How execution is logged and monitored.

Operational value: A mechanism for controlling concurrent ML automation and reducing the risk of conflicting operations, subject to the lock implementation and its failure handling.

23. Infrastructure Connectivity and Network Resilience

Network availability is a fundamental dependency for monitoring, application connectivity and operational support.

I changed the primary ISP from ACT to TATA after the ACT Fair Usage Policy threshold was exceeded and firewall bandwidth dropped to 3 Mbps.

The change addressed an operational connectivity constraint. It also illustrates why network-provider performance should be evaluated against actual business requirements rather than assumed service capacity.

Useful follow-up measurements include:

• Available bandwidth and utilisation.
• Packet loss and latency.
• Connection stability.
• VPN and remote-access performance.
• Incident frequency and duration.
• Failover capability and recovery time.

Where possible, network changes should be validated against representative workloads and documented alongside the associated firewall and routing configuration.

Operational value: A change in primary ISP to address a bandwidth limitation affecting operational connectivity.

24. Observability with OpenTelemetry

I worked on introducing an OpenTelemetry pod in AKS.

OpenTelemetry provides a common approach for collecting telemetry such as traces, metrics and logs through supported instrumentation and collectors. Its value comes from making it easier to correlate application behaviour across distributed components.

For a production rollout, I would validate:

• Which telemetry signals are collected.
• Whether the instrumentation covers the required services.
• Exporter and collector configuration.
• Access controls and protection of sensitive telemetry.
• Sampling, retention and data-volume implications.
• Collector health and telemetry delivery.
• Integration with the organisation's observability platform.

Operational value: A foundation for more consistent telemetry collection and cross-service troubleshooting, with the actual observability improvement depending on instrumentation coverage and integration.

25. Resolving an Infrastructure Capacity Constraint in the Network Path

The network-provider change from ACT to TATA also illustrates a broader operational principle: infrastructure capacity issues can originate outside the application or server layer.

When firewall throughput falls, application symptoms can resemble a backend problem—slow requests, timeouts, unstable remote sessions or delayed monitoring data.

A layered investigation should therefore examine the full service path, including the local network, firewall, ISP, VPN, routing and remote endpoint.

Operational value: A practical reminder to correlate application symptoms with network performance before making unnecessary changes to application infrastructure.

26. Bringing the Improvements Together

The individual changes become more valuable when managed as part of a coherent operational improvement programme.

I group this work into six engineering themes:

Security and control

• Gitleaks integration with CI/CD.
• Wazuh deployment across on-premises servers.
• Trivy upgrade.
• Root-access change proof of concept.
• Certificate trust remediation.
• DNS hygiene.

Reliability and recovery

• Automated backups across multiple platforms.
• Legal-Elastic and Weaviate restoration.
• Disk snapshot recovery for UAT.
• Elasticsearch cluster expansion.
• Kong failover-related implementation.
• Kubernetes health probes and deployment strategies.

Automation and engineering consistency

• Kong API Manager automation.
• Liquibase CI/CD.
• Jenkins upgrade.
• ML deployment automation proof of concept.
• ML automation locking.
• Deployment-script cleanup and version control.

Cloud and API modernisation

• WSO2-to-Kong migration work.
• Azure API Management to OCI API Gateway migration.
• OCI API configuration-limit remediation.
• Jasper API integration remediation using OCI Functions.
• API migration work involving Standard API Manager.

Capacity and platform optimisation

• Pod and Docker profiling.
• ML service rationalisation.
• Ollama configuration and GPU model management.
• Swap configuration.
• Elasticsearch node expansion.

Operational hygiene and environment management

• Linux OS upgrades.
• Service segregation across environments.
• Removal of unused DNS records.
• Network-provider change to address bandwidth constraints.
• OpenTelemetry deployment work.

27. Measuring Operational Improvement

Engineering changes should ultimately be evaluated using evidence. For this programme, I would track a focused set of measures.

Improvement area	Useful measure
Secret scanning	Repositories covered, findings triaged and remediation time
Security monitoring	Server coverage, agent health and high-priority finding age
Vulnerability scanning	Scan coverage, finding severity and remediation status
Backup and recovery	Backup success, restore-test success, RPO and RTO
API gateway reliability	Availability, request errors, latency and failover test results
Kubernetes operations	Pod restarts, OOM events, deployment failures and readiness failures
Capacity optimisation	Resource utilisation, headroom and cost per workload
Automation	Manual effort avoided, automation failures and repeat-ticket reduction
Database delivery	Migration success, rollback or forward-fix events and post-deployment validation
Network performance	Latency, packet loss, throughput and connectivity incidents

I would establish a baseline before claiming a percentage improvement. Where measurements are unavailable, the correct approach is to describe the engineering change and its intended benefit without inventing an outcome.

Conclusion: Engineering Operations as a Continuous Improvement Discipline

These improvements demonstrate how DevSecOps, observability, automation, infrastructure management and recovery planning work together.

Security scanning helps identify risks earlier. Monitoring makes operational behaviour visible. Backup and restoration processes support recovery. Kubernetes health controls improve deployment management. API gateway and infrastructure changes address platform constraints. Automation reduces repetitive work, while capacity profiling provides evidence for optimisation.

The next level of maturity is to connect these activities to measurable operational outcomes: fewer recurring incidents, faster and safer recovery, more reliable deployments, stronger security-control coverage and better use of infrastructure resources.

For me, the central principle is straightforward:

Operational excellence is not the absence of incidents. It is the ability to detect problems early, recover safely, learn systematically and engineer the conditions that make the next incident less likely.

That is the direction I continue to pursue across DevSecOps, cloud platforms, API infrastructure and ML operations.