What if I tell you that for years my job was to maintain transversal tools, work on branching model and promotion, design/setup/operate databases, configure and operate automation servers, architecture build systems and dependencies management, develop/deploy/monitor transversal applications…

You would tell me probably that I’m a kind of DevOps!

And you would be right, I was doing “DevOps” things, even before the word was actually a thing.

What exactly was my work?

A mix between implementing/maintaining tools (jenkins workflows, build system etc…), developing and operating softwares (shooters, dashboards, caching server), handling shadow validation (technical operational validation, autops…), interfacing between our department and infrastructure (VCS, Artifactory, Jenkins agents in AWS), running release integration (gate keeping, releasing, change management etc…), operate cloud namespaces, advocating for good practices, and last but not least to be a knowledgeable support (organically even being first level for topics not under our responsibility).

Of course with such a big panel of activities, nobody is expert in everything but each person has a broad knowledge and some specific expertise, welcome to the T-Shape!

Being “DevOps” means that I worked on engineering topics, on automating as much as possible, ease the dev lifecycle and shift the tests left. That was not bad :)

It was also about spreading and defending engineering good practices (I was not doing that much personally) and, depending the person, it means working more on some specific project. As I said earlier (T-Shape), nobody can work on all the topics (even the most senior team members are not fluent with every projects), but if possible you have to know at least a bit of everything.

It has some drawbacks since being DevOps means like you won’t necessary always feel like a developer every day (does brainstormings, products integration, fixing one line bugs, doing support and editing Jenkinsfile makes you a developer?).

But you will become more full stack than a full stack dev! And you can even look into some pure SRE if you’re interested.

And if I said “DevOps”, I even touch some FinOps (e.g. manage capacity fine tune labels and Jenkins nodes or migrate to another public cloud) or SecOps (but we are still bad in this).

Deploying containers, a lot of containers

And finally SRE!

Then I evolved into the more “Ops” of the “DevOps”, becoming SRE.

Part of my days started to be spent watching dashboards like the following:

In this role I really had to learn SRE principles like putting more attention to manage my time and risks, put prod first and value more and more reliability.

Reliability… I was already very concerned by this topic. Seeing further than development only (How to reduce application data corruption during the time? What version of the tools and modules are in production? How operator will deploy/monitor/troubleshoot my application ? How will be managed evolutions (like data schemas)?) is one of the point that make the difference between a good and a weak developer (or maybe a junior and an experienced developer, but it’s usually a quality more than a matter of time).

So as I said I was already taking extra care of reliability but now it’s just becoming the top priority.

As an SRE you also need to absorb pressure and manage plannings based on external pace (customer deadlines, functional deliveries…).

I remember the rush we had years ago for a prod activation.

The day was planned for weeks (the deadline was crazy, nothing was ready…), we gathered all in one big office (think like a NASA launch but with more casual people), double checked, triple checked all the things and re-checked again, then asked to open the traffic, a command line launched by hand by one carefully chosen colleague. It was changing on a prod machine the load balancing weight and we watched live the first transaction appearing on our dashboard on the big TV.

We were exhausted but what an accomplishment!

SRE is often a demanding job, but you get real reward at the end.

Another period another story.