I've been with my current employer for several years, and I've noticed, as with other employers, that there are unfortunately divisions between developers (Devs) and production engineers (Ops).
A different role in IT
Can you really blame people with different jobs, training, expectations and goals for having difficulty understanding each other?
Be careful, I'm not throwing stones at either side, but I have to admit that the roles of the two parties are not the same, even though dev and ops are complementary in order to have an efficient and effective production, while being innovative.
But here's the thing... when people don't speak the same language, it is difficult to understand each other and to apprehend the difficulty of the other's job. Because, even if it is easy to forget it, developers often play against the clock, to deliver the latest functionality in fashion for the day before yesterday, with often... approximate specs. On their side, production engineers have various roles, the MCO of production already, but also integration, security (which has become more and more important in recent years). I don't intend to be exhaustive on these points, as Dev/Ops roles vary from one company to another.
Chaos to bring together
From there, we come to the question of how to facilitate the rapprochement between the two worlds. We often hear about feature teams, which are in vogue, especially among the GAFAMs, with the logic "you build it, you run it". And it works! But why? Quite simply because the worries of a dev also become the worries of an Ops, and vice-versa, since this division no longer exists as such.
For my part, I had the opportunity to have another approach, I participated in two gamedays in collaboration with AWS within my company. The goal? Within a fictitious unicorn rental company, Unicorn Rentals, to set up an infrastructure based on exercises created by Amazon.
A little subtlety, this day takes place in a team, and especially in a mixed Dev/Ops team. It's a very intense day, where collaboration is essential to win. Through production issues (stabilizing a service, optimizing infrastructure performance, network incident etc...) and development issues (setting up code for image recognition, restarting a deployment pipeline with code testing etc...), this day brings together people who see differently their respective jobs and skills.
I've seen changes in the relationships I can have with my colleagues, going from a simple "hello" to real questions, requests, concrete technical exchanges, requests for advice etc... From my point of view, for me, who comes from the world of Ops, having held several engineering positions in recent years, this has allowed me to see differently the knowledge of some of my fellow developers.
Organize Chaos Days independently
On our side, we chose to ask Amazon to organize these days, however, it is completely possible to organize this type of event with its own infrastructure, this allows for example to test the quality of documentation, backups etc ... the important thing is not so much the content but the way to approach these days.
Quite simply, it is necessary :
- To have mixed DevOps teams
- To create problems requiring collaboration between the two parties
- A "competitive" spirit catalyses the way of working
- Not taking this day seriously
- A person or persons to help, so that no team is frustrated if it is too far behind, as in the previous point, maintaining a competition is necessary.
In addition, a few souvenirs:
This article is based on my own experiences and does not necessarily reflect the views of all my colleagues.