Bram Vogelaar
Bram Vogelaar spent the first part of his career as a Molecular Biologist, he then moved on to supporting his peers by building tools and platforms for them with a lot of Open Source technologies. He now works as a devops engineer at the Factory, a cloud consultancy in the Netherlands
HashiCorp Bram Vogelaar spent the first part of his career as a Molecular Biologist, he then moved on to supporting his peers by building tools and platforms for them with a lot of Open Source technologies.
He was one of the first to achieve all 4 HashiCorp certifications and was selected both as a HashiCorp Ambassador and Core Contributor to HashiCorp Nomad for 2023. He now works as a software engineer at seaplane.io where he builds infra structure for all their AI needs
Sessions
Athletes, Firemen and Doctors train everyday to be the best at their chosen profession. As engineers we spend much of our time getting stuff to production and making sure our infrastructure doesn’t burn down out right. We however spend very little time learning to understand and respond to outages. Does our platform degrade in a graceful way or what does a high CPU load really mean? What can we learn from level 1 outages to be able to run our platforms more reliably.
Back in the day in a IT company long ago, where the BOFHs roamed and the ITIL was strong. We used to keep long lists of CIs that used to enviably and hopelessly out of date. Because we either didnt care, know or bother keeping up to date. That was totally fine in a relatively static environment the IT company of long ago. We would have our yearly inventory day and forget about it again.
Of course we all use some form of infrastructure as code right now. Some of us might go as far that "if it isn't in code it doesnt exist", but can we truly say that whatever is in the OpenTofu state really is the only thing running? What about that recurring 1$ in that dormant AWS account, where is that coming from? How about the playground projects the CEO likes to play around with in his sparetime? or that one time the opentofu destroy didnt exit cleanly and some resources weren't cleaned during that timeout, did we really manually cleanup all resources?
We all know the wall of illegible wall of small graphs, that we like to present to (senior) management and auditors as proof that we do observability. It doesnt matter that the person ( and the associated knowledge) has long since left the company, nor that the dashboard doesnt autorefresh and still show the same data from when we turned on the monitoring PC.
In an ever changing IT landscape we deserve better than that. We shouldn't have to rely on the gut instinct of the senior engineer on deck about the general shape of the dashboard to know where to start fixing whatever it is that needs fixing.
We should aim to collect and present such information both from the it and business side that let a relatively inexperienced oncall engineer differentiate between a P1 incident and a major client/customer/continet going to bed.
We should be telling beautiful stories with data and dashboards in such a way that (even) management can pull up global dashboard and can determine business relevant information like "is our advertisement campaign having any impact". We should also not be afraid to have multiple dashboards that show different relevant information to stack holders (e.g sales figures for management and links to runbooks for engineers)
https://www.slideshare.net/slideshows/scraping-metrics-for-fun-and-profit/266147160