Systems, networks and cloud internships: understanding what keeps services running

What is meant by IT infrastructure

An application that we use without thinking rests on a set of layers: physical or virtual machines, an operating system, a network linking those machines to each other and to the outside world, account directories, backups and monitoring tools. Systems teams look after servers and their configuration, network teams handle links, firewalls and connectivity, and cloud teams manage resources rented from outside providers.

These boundaries move. In many companies, a single department covers all three, often under the banner of operations or DevOps. An internship or apprenticeship in this field therefore means joining a coherent whole, where you first learn to observe and only then to act.

Internship or apprenticeship: two ways into operations

An internship, covered by an agreement between your school and the host organisation, suits a first immersion of a few weeks or months within a vocational diploma, a university technology degree, a professional bachelor's or an engineering school. In France, an allowance becomes compulsory beyond a certain length; its minimum amount is set by regulations and changes, so check it when you sign.

An apprenticeship makes you an employee in training. It is very common in infrastructure jobs, because companies see it as a way of gradually training someone in their own environment, which takes months of learning before a person is independent. The rhythm may be two weeks in the company for one week in class, or other patterns depending on the school.

In this field, an apprenticeship has one particular advantage: you will only be given wide administration rights once you have proved yourself, and the long duration allows that trust to build up.

Possible tasks for a beginner

It is rare to entrust a critical production system to an intern. Realistic tasks are more like these:

• creating, changing or disabling user accounts following an approved procedure;
• installing and configuring a virtual machine on a test environment;
• handling simple requests from a ticketing tool, with validation from a supervisor;
• writing short scripts that automate a repetitive task;
• preparing an inventory of the equipment and services on a site;
• checking that backups run and that a restore is possible;
• updating documentation and architecture diagrams.

Each of these tasks teaches the same lesson: a well-prepared change is one where you know the state before, the expected state afterwards and the way to go back.

Skills to build before applying

The technical basics

• Linux on the command line: files, permissions, processes, services, logs;
• Windows Server and account directories, in principle;
• the model of communication between machines: addresses, masks, gateways, domain names, ports;
• virtualisation and, if possible, containers;
• a scripting language such as Bash or PowerShell, or even Python;
• basic cloud notions: virtual machine, storage, virtual network, access management.

The qualities that make a difference

Rigour first: noting what you do and checking before you validate. Then curiosity, to understand why an incident happened rather than restarting the system and hoping the problem disappears. Finally a sense of service, because you will deal with users who have no need to know the technical vocabulary.

A home lab to prove your method

You do not need expensive equipment. A decent computer, virtualisation software and a few system images are enough to build a small test network: a Linux server hosting a service, another providing domain names or addressing, a client machine and a virtual firewall.

For an application, the value does not come from the size of the lab but from how you describe it:

1. describe the starting objective and the diagram you ended up with;
2. list the commands you really understood, with the result you observed;
3. explain a failure you caused or suffered, and how you diagnosed it;
4. say how you return to the initial state.

This exercise also stops you from touching a company system without having understood it, which reassures future tutors a great deal.

Being welcomed in good conditions

In infrastructure, one mistake can interrupt the work of many users. A serious induction reduces that risk. From the first interview, ask a few simple questions:

• will you work on a test environment or on production?
• what access rights will you be given, and who approves them?
• who reviews your changes before they go live?
• is there on-call duty, and is an intern involved?
• which ticketing tool and which documentation will be used?

On-call duty, meaning being available outside normal hours to deal with an incident, mainly concerns experienced employees. If this possibility is mentioned, ask how it would be supervised and paid before you commit.

Where to look: hosting providers, operators, IT services firms and IT departments

The host environments form a wide range. Hosting providers and cloud suppliers offer direct contact with data centres and large-scale platforms. Telecommunications operators expose you to wide-area networks. IT services companies place their apprentices with varied clients, which speeds up your discovery of different contexts. The IT departments of hospitals, local authorities, manufacturers or banks let you learn operations in the service of a particular business.

To improve your chances, combine the offers published by schools, alerts on job sites, student fairs and unsolicited applications sent directly to an operations manager. Mention in your message a technology the company uses and that you have tested in your lab: it is an excellent argument.

An illustrative example: six months around a file server migration

A fictional illustration, with rounded figures. Karim, a second-year apprentice on a vocational diploma, joins the IT team of a company with one hundred and fifty employees. His tutor gives him the inventory of an old file server, then the preparation of its replacement.

He starts by mapping the shared folders, their permissions and the real usage: about forty folders, ten of which have not been used for a long time. He then writes a three-step migration procedure, with a rollback point planned before each step. The switchover takes place one evening, supervised by his tutor; Karim checks access, records the problems and writes a guide for users.

By the end of the project, he has understood the idea of a controlled change, practised communicating with users and left documentation that will serve his successors. This is what an operations team values.

Mistakes to avoid at the start

• Acting without understanding: copying a command found online onto an important machine without knowing its effects.
• Forgetting to document: a change that is not recorded becomes a mystery for the next team.
• Underestimating backups: a backup that has never been restored is only a hypothesis.
• Keeping a doubt to yourself about an operation: better to ask the question than to fix things afterwards.
• Neglecting access rights: keeping a high-privilege account longer than necessary, or sharing a password.
• Aiming only at fashionable tools and leaving aside the fundamentals of networks and systems, which remain valid from one supplier to another.