WWNIT SOLUTIONS
WWNIT Solutions

Cases

Back
WWN
IT SOLUTIONS
PROJECT FILE03 / 05

PRODUCTION INFRASTRUCTURE

Less manual setup and fewer recurring failures

Automating e-commerce configuration changes and restoring the reliability of a service developers use to investigate errors.

Changes needed manual work; failures needed intervention

Infrastructure configuration was applied manually, with errors causing retries and delays. Separately, the Sentry error-tracking service periodically stopped working after backups. Developers had to interrupt their work to restore it.

Automated configuration and service recovery

Configuration changes run through an automated GitLab workflow. Disk blocking during backups was identified as the cause of Sentry failures; consumer recovery, monitoring and failure alerts were configured.

Routine changes follow a prepared workflow

Engineers no longer need to repeat each configuration step manually. Service health is monitored separately so failures can be detected.

  1. An engineer updates configuration defined in code and starts the GitLab workflow.

  2. Automation applies the configuration instead of a sequence of manual steps.

  3. Monitoring tracks service health; recovery is configured for Sentry consumer failures.

Technical diagram and tools
Technical diagramLOGICAL CONNECTIONS

→ action or data flow · — functional relationship. Repeated blocks refer to the same component.

Changes

  1. IaC configurationTerraform · Ansible
    Configuration
  2. GitLab CI · JenkinsApplying changes
    Apply changes
  3. Kubernetes · HelmApplications and environments

Application images

  1. HarborRegistry maintenance
    Images
  2. KubernetesApplication images

Application errors

  1. ApplicationsIn Kubernetes
    Error events
  2. Sentry · SnubaError processing

System health

  1. Apps and environmentIn Kubernetes
    Metrics and logs
  2. Grafana · ELKMonitoring, alerts and logs

Secrets and access

  1. Vault · LDAPSecrets and access
    Access management
  2. ApplicationsIn Kubernetes

Sentry/Snuba and Grafana/ELK serve different observability needs. They are not a sequential error-processing pipeline.

Terraform · Ansible
Infrastructure configuration
GitLab CI · Jenkins
Applying changes
Kubernetes · Helm
Applications and environments
Sentry · Snuba
Error processing
Grafana · ELK
Monitoring, alerts and logs
Vault · LDAP
Secrets and access
Harbor
Registry maintenance

Terraform · Ansible · GitLab CI · Kubernetes · Helm · Grafana · ELK

Example: Sentry reliability

Diagnosis linked Snuba consumer failures to disk blocking during backups. Restarts, monitoring and Grafana alerts helped restore stable operation, and the previous outages stopped interrupting developers.

Configuration deployment is about three times faster

Automation replaced manual configuration changes that involved errors and retries. After the backup-related failures were addressed, developers no longer need to restore Sentry manually.

  • Configuration changes launched through GitLab.
  • Automatic recovery of Sentry consumers instead of manual intervention.
  • Monitoring and alerts for service health.