Selectel Cloud Infrastructure: Where It Breaks
The Selectel cloud infrastructure is designed so that it is easy to manage manually: servers, networks, load balancers, and storage are provisioned from the panel in minutes.
The problem starts later — some environments are described in the policy, some live in the engineer's head, and some were edited at night in the terminal when things were on fire.
This is how configuration drift appears: the actual state stops matching the described one, and no one can name the point where they diverged.
The cost of the discrepancy shows up at the worst possible moment. A planned change — resizing a server, moving a subnet, editing access rules — brings down prod because dependencies between services are not recorded anywhere.
An unpredictable network finishes it off: routes and security groups are edited on a point basis, and each such touch turns into a separate risk of downtime due to changes.
Hence also reproducibility. The test environment does not replicate the production one, so pre-release checks prove nothing, and rollback after a failed update is done manually and from memory.
The more environments there are, the more expensive manual server management becomes: engineers spend time not on product development but on restoring what already worked.
We break down how this is addressed: which infrastructure state is considered the reference, how divergence from it is checked, and what describing the environment instead of a set of manual actions provides.
What Changes After Moving Services to a Managed Cloud
Moving to a managed cloud changes not the composition of services but the way infrastructure is handled.
Configuration stops being a set of manual actions in the panel and is described as code: files live in a repository, pass review, and are applied identically for the staging and production environments.
In Selectel, this maps to the provider's native resources — networks, load balancers, and clusters are described by the same files as the application.
The first measurable effect is the speed of releasing changes. The environment is deployed with a single command, divergence between environments is visible at the review stage rather than at release time, and every change rolls back to the previous description. Release frequency grows without an increase in the number of rollbacks.
Service recovery time stops depending on the speed of the on-call engineer.
A failed node is recreated from the description, traffic moves to live instances, state is pulled from replicas — a typical failure is resolved without manual intervention, and downtime consists of minutes instead of hours of diagnostics.
An entire class of failures caused by manual edits also disappears: a setting was updated not on all servers, access was granted to only one environment, the sequence of actions diverged from the documentation.
A declarative description removes the very possibility of such divergence, and the share of manual operations falls to edits of the descriptions themselves.
At the same time, fault tolerance stops being a property of individual machines: it is built into the placement scheme across zones and verified by node shutdown drills.
Deployment Options: Cloud Infrastructure or Your Own Servers
Deployment in the cloud is not a choice between two poles but a scale between control and the amount of maintenance.
Managed services cover databases, queues, and object storage: the provider is responsible for fault tolerance and updates, while the team is responsible for the schema and queries.
Your own virtual machines give full access to the operating system and network, but updates, backups, and monitoring remain on your side.
Between them are the hybrid scheme and dedicated resources. The hybrid keeps data in its own environment while moving the web layer and processing to the cloud; dedicated resources are taken where the load is predictable and isolation matters.
The limitations of each mode show up on a specific load profile, so we look at it rather than at how trendy the approach is.
| Option | When it fits | Limitations |
|---|---|---|
| Managed services | Load changes, a fast start is needed, the team is small | Some settings are unavailable, dependence on the provider's API |
| Your own virtual machines | You need your own versions, agents, non-standard network topology | Updates, backups, and monitoring are on your side |
| Hybrid scheme | Data must remain in its own environment | Two environments: more complex networking and unified observability |
| Dedicated resources | Predictable high load, isolation requirements | Longer setup, resources sit idle during a decline |
We describe each option with configurations in a repository: one set of descriptions deploys managed services, machines, and the hybrid, so changing the mode does not mean rewriting the project.
In Selectel cloud infrastructure, we have assembled all four schemes and know where the provider's limitations begin.
Workflow: From Audit to Handover to Operations
The work proceeds in fixed stages, and each stage is closed with an artifact: a configuration, a diagram, or a verification report.
The customer can see at any moment at which step the Selectel cloud infrastructure is and what has already been taken into work — without waiting for a final presentation.
- Infrastructure audit. We inventory what is running where, which services are connected to each other, where manual operations and single points of failure remain. The output is a map of the current state with a list of risks and priorities.
- Network and target environment design. We fix segmentation, access rules, routing between subnets, and backups. The design is agreed upon before setup begins so the environment does not have to be redone along the way.
- Environment description as code. Configuration is stored in a repository, not in checklists: the environment is brought up from the description and reproduced one-to-one — the test one replicates the production one.
- Load testing. We run scenarios on the peak profile, look at response time and behavior when an individual node fails. Bottlenecks found are eliminated before migration, not after.
- Service migration. We migrate in groups, starting with non-critical ones, with reverse switchover to the previous site. Data is transferred with integrity checks and checksum verification.
- Documentation. Recovery policies, diagrams, instructions for the on-call team, and the change management procedure — what the environment lives by without us.
- Handover to operations. We hand over access, train the team, and assign those responsible for changes. After that, we remain in contact for planned improvements.
This order removes the main risk of infrastructure projects — when the environment works, but no one understands how to repair and change it.
Handover Package: Diagrams, Access Policies, Procedures
The package is assembled during the work, not after acceptance: each step is recorded in the documentation and in the configuration description, so the environment can be deployed again without restoring the logic from memory.
Below is what exactly the customer receives along with the working infrastructure in Selectel cloud.
- Infrastructure diagram — networks and subnets, external exit points, distribution of roles between servers, connections between services, and which zone fails in isolation. The diagram reflects the actual state, not the project.
- Configuration description as code — a repository from which the environment is brought up again. Changes pass review before being applied, and similar environments stop diverging from each other.
- Access policies, roles, and permissions — what is available to a person, what to a service, which accounts are separate, and where shared access is unacceptable. Revoking permissions when an employee leaves is performed with a single action.
- Backup procedure — what is copied, how often, what retention depth is used, and where copies are stored. Separately recorded is how recovery is verified and how long rollback takes.
- Operations procedures — image updates, planned maintenance, change management procedure, failure response, and points where service owner approval is required.
- On-call instructions — what to look at at the first signs of failure, where to escalate, and which actions are safe without approval.
- Handover to the team — a walkthrough of the setup on a call, issuance of access, and answers to documentation questions until your engineers begin running the environment themselves.
Case Study: Migrating Services Without Downtime
Initial state: dozens of virtual machines configured manually. The configuration of each environment differed, changes were made manually on live servers and were not recorded anywhere — after an engineer left, there was nothing to restore the environment's logic from.
Rollback after a failed release meant deploying a snapshot and manual reconfiguration, that is, hours of downtime at the worst moment.
We migrated the load to a described environment on Selectel: the infrastructure stopped being a set of live servers and became a description in a repository.
Environments are brought up from a single set of files with parameters, state is compared with the description automatically, and divergences are visible before rollout, not after.
Metrics Before and After
| Metric | Before | After |
|---|---|---|
| Deploying an environment for a task | two days of manual work | 25 minutes |
| Release rollback | snapshot restore, hours | traffic switchover, minutes |
| Divergence of settings between environments | searched manually | caught automatically |
The migration proceeded without downtime: data was replicated to the new environment, traffic was switched during a window of minimal load, and the old scheme remained operational until the metrics were confirmed.
The rollback plan was written in advance — reverse switchover in one step, without restoring from archives and reconfiguring servers.
What to Do If Some Services Are Already on Your Own Infrastructure?
Hybrid infrastructure is a working state, not a transitional crutch: some services remain on your own infrastructure, while some move to the cloud.
What is usually kept on your own infrastructure is what is tied to data, licenses, or already purchased equipment, while growing load and services with frequent releases are moved to the cloud.
There is no need to move everything at once — it is enough to connect the sites so that they work as one system.
We build connectivity between sites on a private segment: encrypted tunnels over public channels or a dedicated line if there are latency requirements.
We plan address spaces without overlaps, write routes explicitly, and traffic between services goes over private addresses and does not go out to the internet. We provide channel redundancy: if one route breaks, the second automatically takes over the traffic.
A single entry point removes the main difficulty of a hybrid: the application does not need to know at which site its part lives.
At the entry we place a load balancer with health checks, and behind it — services from both sites; a short TTL in DNS moves traffic to the new site in minutes. Internal systems and users access a single address, so migration does not require changes on their side.
Gradual migration proceeds in waves by class of service. First we migrate services without local state: build an image, describe the configuration as code, shut down the old node.
Then services with data: enable replication, read from the copy, compare divergences, and switch writes in a short window. Every step is reversible — the old resources remain in service and take the load back if the metrics go the wrong way. This is how a hybrid is assembled in several iterations, without stopping the product.
Common Technical Questions: Access, Security, Rollback
Accesses, backups, and responsibility boundaries are checked before the start, not after the first failure.
Below are answers to what most often comes up during coordination: how access to Selectel cloud infrastructure is separated, what will remain with your team after the project, and how the environment is restored.
How is access to the infrastructure separated?
According to the principle of least privilege: each engineer works under their own account, automation — under separate service keys with a limited set of permissions. Only on-call engineers have access to the production environment, and all actions are recorded in the audit log. Keys are not shared in messages and are rotated when the team composition changes.
What will happen to our accounts after the project?
You remain the owner of the account — we work as invited participants with our own roles. During handover, we revoke our access, rotate automation keys, and provide a list of active accounts with a description of permissions. Separately, we record which service keys need to be reissued.
How are backups organized and is recovery verified?
Copies are taken on a schedule and stored separately from the main environment so that a site failure does not take the data with it. The key is not the presence of copies but regular verification: we deploy the environment from a copy and measure the time to a working state. Without such verification, a backup is considered not ready.
What is the recovery plan after a failure?
The entire infrastructure is described as code in a repository, so the environment is reproduced from scratch rather than assembled manually. There is a response procedure with service priorities and the on-call engineer's sequence of actions. This approach removes the class of failures where recovery depends on a specific engineer's memory.
Where is the contractor's responsibility boundary?
We are responsible for the infrastructure code, configuration, automation, and environment recovery. On your side are the application's business logic, data, and ownership of the cloud account.
We record the boundary in writing before the start so that during a failure there is no need to determine whose area it is.
Let's Discuss the Task and Come Back with an Estimate and Plan
The more specific the input data, the fewer clarifying rounds and the more accurate the project estimate.
Send not "we want to go to the cloud" but a snapshot of the current state: what already runs at the provider, what remains on your own machines, how services communicate with each other.
- Diagram of services and connections between them — even a hand-drawn sketch or a list without details is better than nothing.
- Load profile: peak periods, seasonality, availability and recovery time requirements.
- How many environments are needed (development, test, production) and how they differ in composition.
- Constraints: security requirements, internal regulations, existing contracts with vendors.
- Access issuance procedure: who approves, whether a separate account is needed for automation.
- Pain points: where manual operations currently are, what most often breaks, which tasks take up time.
- Desired timelines: launch date and windows in which migration is acceptable.
In response, you receive an implementation plan broken down into stages: inventory and target design, infrastructure description as code in a repository, a pilot on one environment, migration of the rest, and handover of support.
For each stage — the scope of work, timelines, and what is required from your side. Separately, we agree on the interaction scheme: one communication channel, responsible parties on both sides, regular status checks.
Describe the task in free form — we will come back with an estimate and a plan.