My first journey as an SRE at Docplanner
Good morning! Guten Morgen! Buongiorno! Buenos días! Dzień dobry! — A lot of different languages we speak in the Platform and Reliability (PnR) area here at Docplanner. This diversity of origins, technical skills, languages, and so on - brings enormous value to our squad.
This post will be a bit personal, so please be patient. At the beginning of 2022, I re-joined Docplanner after a year and a half break. Previously, for over eight years, I was doing my job as a software engineer in many different technologies, such as PHP, Golang, Elixir, a bit of Ruby, and Python. Well, making product well is something that I love, but even more, I love to make things more stable, more reliable, and faster. I fall in love with a quote from an SRE book (this from Google):
Reliability is the most important feature. If a system isn’t reliable, users won’t trust it.
January 2022 — I joined the PnR as a person actually without more experience in areas such as cloud engineering. That was under the SRE-wannabe program. Let’s say a few words about it before we dig deeper into my journey.
SRE wannabe program — what’s this?
Here at Docplanner, we believe that if you have a solid understanding of software engineering (distributed systems, software architecture, coding, etc), and you are eager to learn, then you are a good person to work on reliability-related topics as an SRE. This role (wanna-be Site Reliability Engineer) is about continuous learning and being committed to projects around the system’s stability, availability, performance, monitoring, and so on. During your work as a wannabe SRE, you’ll learn a lot about infrastructure, and the daily work of our SRE colleagues.
Going back to the story…
I was super lucky because I’ve got a brilliant buddy — Przemek. In general, a buddy is a person who helps you with your daily struggles with the ecosystem, tooling, and practices used in the team, and Przemek did it well (thank you!). Day by day, I’ve been more engaged in other projects and areas of ownership. The opportunity to join incident response calls gave me an overview of how to react in specific situations.
Ten months after joining the team, I see how big steps we have taken as a team — in terms of maturity, shared ownership and connecting the dots. Even though the squad has grown by 12 people in this team — we can scale up our job and organize ourselves. Maybe that’s a result of experimenting with the holacracy approach. Well, it’s irrelevant. What is relevant is this we do the job, and we do it properly. You probably know that some companies just changed the name of the SysOps/DevOps team into the SRE, and except that nothing more has changed. In our case, it’s different. We code and care about the customers.
Coding
Do I miss coding the product? Well, not at all. Building a platform around our ecosystem is even more satisfying because of its impact on the whole system. I’m a bit data-driven guy, so keeping an eye on metrics in observability tools is quite natural. Also, being in this team is an excellent opportunity to get a grasp of working with different tools. If you feel that your learning curve has slowed down — joining such a team is a fantastic chance to get it up. Is experimenting with different approaches exciting for you? Then you have the same answer: the SRE way might be a good career path for you.
Team skills
What do I appreciate in my team? A variety of skills and specializations people have. We have engineers with security-oriented knowledge, cloud-related knowledge, software engineering practices knowledge, hardware knowledge, and so on. It is amazing! If you bring any problem to the team — you’ll find someone who is an expert in this area.
Theory of constraints
A part of the DevOps mindset is eliminating constraints and being in harmony with a theory of constraints. Do you have problems with noisy alerting systems? Focus on it, reduce the noise, and find another thing that blocks you. Related to this, we have introduced SRE Day. It is a recurring initiative where we split the team into smaller groups with different skill sets. Each Wednesday, one of the groups focuses on solving a real problem/improvement that we don’t focus on every day. On that day, we are off for meetings. We are just solving the problem together. It’s also another way to integrate team members. The next day, we meet with others from Platform and Reliability to discuss everything we’ve learned, what we’ve done and how it affects our area.
Well, after these ten months of a different kind of work that I did in the past, I feel so good. The real impact, tons of opportunities, and fantastic teammates — it’s something that drives me to be as good as possible. Would I have made the same choice of career path? Yes, it’s incredible!
If you are curious about something we do — feel free to reach me on LinkedIn. I would be happy to help and talk!
