00:00:11.920
Hey everyone, thanks for coming down. Can everyone hear me at the back? Got a wave? Awesome! So yeah, thanks for coming down today. I'm going to talk a little bit about how to rethink production monitoring.
00:00:19.560
That's quite a broad topic, but I'll dive into it in a lot of depth.
00:00:26.039
But who the heck am I? You can probably tell by my accent that I'm not from around here. I'm originally from the UK and I've been working in the Bay Area for the past seven years.
00:00:38.079
I've also been building production monitoring systems for over ten years, originally in finance when I was working at Bloomberg, then at a startup, and now at Bugsnag, helping people do better production monitoring in their own teams.
00:00:51.120
Just a quick overview of Bugsnag: I think a lot of people may know about Bugsnag or have used a similar tool. We help you understand what's going wrong in your software in production.
00:01:01.320
Instead of receiving a slew of emails from the exception notifier gem, or digging into your log files or using an older tool like Airbrake, we provide you with the tools and workflow you need to identify the most important problems in your software.
00:01:14.439
We highlight answers rather than just data. I think Skylight used that term as well, but we focus on identifying the most harmful bugs and errors in your applications.
00:01:20.280
I'll be talking a lot about the philosophies and techniques we use when building Bugsnag. However, this is more of a general talk about setting up good quality production monitoring and ensuring that you're not dropping anything.
00:01:41.960
This is the scary reality for many companies. If people are honest with themselves, most are doing this: "Let's build some code, let's write tests. Most people are doing a good job of writing tests these days. Let's send it out to production, and then I guess it's okay. It's probably fine." But what you really want is confidence.
00:02:08.160
You want to be sure that when your code is live and your customers are using your product, it's working properly. I'll talk a bit about how you can move from the left to the right side of this process and gain confidence in your software.
00:02:21.400
So, what is production monitoring? It breaks down into three core areas: stability monitoring, performance monitoring, and availability monitoring. Stability monitoring is what Bugsnag does; it detects if your software is broken and alerts you if crashes are occurring.
00:02:53.360
Performance monitoring, on the other hand, includes tools like New Relic that inform you if your application is running slowly, and availability monitoring focuses on uptime, something like Pingdom. Essentially, it's checking if your site is responding to requests.
00:03:06.319
But really, all of these aspects aim to deliver an exceptional experience to your customers. That's the point of production monitoring. But why do we care about that?
00:03:31.080
It's easier to make software than ever before. Particularly in the Rails and Ruby communities, there's a wealth of tutorials available, enabling you to build applications quickly. However, your app's success depends on its quality.
00:04:07.120
For example, if you are trying to purchase a TV and your app crashes, you'll likely switch to another app like Amazon's to complete the transaction. It doesn't matter where you get the TV from; what matters is making the purchase.
00:04:27.080
If your app is broken, slow, or unavailable, your customers will be frustrated and may leave. A reality based on a retention study conducted a year ago revealed that 84% of customers will abandon your software after just two crashes.
00:05:01.560
You may have invested significant time creating a valuable product, but if your app falters, customers will simply choose not to use it anymore. Moreover, unhappy customers often express their grievances online, whether on Twitter or the App Store, leading to permanent damage to your brand.
00:05:34.240
Conversely, there's a study we've repeated a couple of times that suggests 49% of engineering time is spent on finding and fixing bugs. This figure is consistent across many teams, and it's incredibly frustrating, as engineers prefer spending time building features rather than resolving issues.
00:06:13.680
On one side, you have a customer base that you painstakingly cultivated, abandoning your product due to stability, performance, or quality issues. On the other hand, you are wasting your own time as an engineer or engineering manager.
00:07:09.000
I've created a list of the deadly sins of production monitoring. Many people are guilty of one or more of these. The first sin is pretending that nothing is wrong. Some teams operate under the outdated belief that shipping to production is the final step of the process.
00:07:54.600
They think they can produce something, ship it, and walk away. However, modern software development focuses on deploying code as quickly as possible, observing its performance in real world conditions, and learning from it.
00:08:52.360
You should not assume everything is fine after shipping; this often leads to complacency. One common pitfall is assuming that writing tests guarantees quality. While it's true that most organizations work hard to write tests, no team can write tests for every potential scenario.
00:09:46.120
To complicate matters, too many organizations rely on QA teams, thinking they are responsible for all testing and oversight—even in teams without any QA staff.
00:10:23.640
Next, we have waiting for customers to complain. This is a significant mistake. Waiting for that first complaint ignores the reality that many customers won't voice their concerns, thus leading to a much larger churn.
00:10:49.760
By the time you hear a complaint, you may have already lost several other customers. If you allow your app to continue to fail, you've failed your customers already.
00:11:03.880
Lack of visibility is another critical problem. If you implement logging without actively monitoring it, you won't know if there are issues at hand. Many teams mistakenly assume that logging means they're covered.
00:11:52.079
For example, I've observed cases where teams rely on log files, assuming they can track issues through them—but in reality, log files can become a black hole where data goes unnoticed.
00:12:54.480
Once you have some visibility, it's essential to establish ownership. If your monitoring tools are not owned by someone, little will be done to fix problems.
00:13:21.480
Having a clear ownership structure ensures that there is accountability for addressing issues. Moving on to how we can improve production monitoring, I've developed a set of core principles that can be applied across all areas of monitoring.
00:13:57.600
First, accept that your software will break after shipping. Once you acknowledge this, you'll be more relaxed and less arrogant. You'll recognize that while you're a skilled programmer, things will inevitably go wrong.
00:14:17.080
By adopting this mindset, you'll be well-positioned to iteratively improve your application based on real-world feedback. Second, use tools that detect problems automatically. This will save you time digging through log files or relying on various alerts.
00:14:53.040
Most programming languages provide exception hooks. Utilize these to catch issues where they occur. For instance, in Ruby on Rails, you can configure middleware to capture exceptions and manage how they propagate up the stack.
00:15:39.680
You can also establish performance monitoring to assess how long requests are taking and get alerts when specific parameters are exceeded. Finally, leverage existing tools, like Bugsnag's SDKs, which allow you to capture diagnostic data.
00:16:12.960
Once you set everything up and start receiving data, it's crucial to manage the noise generated by all the alerts. Prioritize what you focus on by determining which issues have the broadest impact on users.
00:17:06.840
Aggregation plays a vital role here; for instance, if many errors stem from one line of code, fix that first rather than trying to tackle all errors individually.
00:17:57.280
To achieve visibility into these issues, utilize team chat platforms to streamline communication. Instead of relying on email notifications, which can quickly become overwhelming, push those important alerts into channels where your engineering team already communicates.
00:18:50.160
Once notifications are aggregated in your teamwork channels, you can filter through them and prioritize issues that impact the most users. Prioritization requires consideration—how many users were impacted, the severity of each error, and other related attributes.
00:19:53.600
It's important to ensure that you have the necessary diagnostic data available at the time a production issue arises. Understanding the context of an error—like what caused it or how many users are being affected—helps you mitigate its consequences.
00:20:37.240
At this point, I cannot stress the importance of ensuring that someone is responsible for addressing these issues on your team. Every organization, regardless of size, should prioritize assigning responsibility so that any detected problems can be promptly addressed.
00:21:41.200
That said, how you choose to structure your team to manage production monitoring can take different approaches. One viable method involves creating a dedicated bug team tasked with monitoring production tools and identifying urgent problems.
00:22:36.600
This model can work, but it has drawbacks, as it may hinder individual developers from learning from production incidents. Another method involves running a rotation system, having team members take turns being responsible for bug monitoring for a period.
00:23:41.640
Finally, there’s the notion of accountability. The last person who modified the code may have insights into the cause of a problem. This way, they can work through the issue or provide context on why it’s happening.
00:24:23.520
A measured approach towards handling post-deployment bugs should strive for a blame-free culture. Establishing this kind of environment allows software engineers to learn from their mistakes while working collaboratively.
00:25:19.440
To conclude, as you work to avoid the sins of production monitoring, adhere to the core principles of quality assurance: accept that software will break, implement automated error hooks, and aggregate your error data.
00:26:10.640
Make use of team chat for notifications, prioritize critical issues, and ensure that you can access diagnostic data. Lastly, make certain that there is accountability—someone should be responsible for acting on detected issues.
00:27:08.640
These core tenets should inform your workflow as you seek to bolster your production monitoring strategies.
00:27:36.480
Are there any questions? (pause for audience questions) That’s a great question. When you have a lot of bugs that seem to appear at a similar level of priority or frequency, how do you prioritize fixing them?
00:28:07.920
One approach is to simply have a team project where you identify and address the most pressing issues. Another technique, known as 'declaring bankruptcy,' involves identifying duplicate bugs and cleaning house to reduce clutter.
00:28:56.440
We recently added a feature to Bugsnag that allows you to ‘snooze’ alerts, meaning if you’re not concerned about a specific issue right now, you can temporarily mute it while still being notified if it worsens.
00:29:51.680
This creates a more manageable situation instead of overwhelming developers with alerts. If a significant number of errors occur due to the same root cause, focus on fixing that specific issue first.
00:30:47.600
In summary, building and maintaining an effective production monitoring framework entails comprehensively addressing these concerns through thoughtful processes and cultural shifts. Avoid pitfalls where you feel everything’s okay and empower your engineering teams to speak up when issues arise.
00:31:53.760
Keep the lines of communication open; learn from feedback, prioritize action items, and surely you will manage to thrive in a quality-focused development environment.
00:32:12.960
Thank you all for joining me today and I look forward to seeing you successfully develop and monitor your applications.”
