Opslogger: Operations code (should be) production quality too!
•
3 likes•514 views
As presented to the London Continuous Delivery Meetup on Feb 23, 2016. Most experienced agile developers have a pretty good idea of what quality production code looks like these days. And we also know that operations code is an important part of quality and stability in production. And yet why is it that our operations code isn't built to the same standard of quality that the rest of our code is? This talk is about how it deserves to be, why I'm unsatisfied with how standard logging libraries approach this problem, and a potential alternative that I think is better.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Opslogger: Operations code (should be) production quality too!
Similar to Opslogger: Operations code (should be) production quality too! (20)
Recently uploaded
Recently uploaded (20)
Opslogger: Operations code (should be) production quality too!
- 3. FullDisclosure Most of this is true for all operations infrastructure.
- 4. FullDisclosurePart2 I’m not in ops. I’m a dev.
- 5. HowAnAgileFeatureIsDeveloped • A customer need is identified • Design with a customer representative • A feature story is written • Prioritised
- 6. HowAnAgileFeatureIsDeveloped • YAGNI check • Tested • Developed • Refactored
- 7. HowAnAgileFeatureIsDeveloped • Demoed to customer representative • Marked as “done” • Deployed to production • Feedback is gathered
- 8. HowAnAgileFeatureIsDeveloped (and sometimes) • Updated or tweaked • Feature is decommissioned
- 10. Whathappensinstead • Feature stories aren’t written at all • They aren’t tied to a customer • They aren’t prioritised • “Do something with logging”
- 11. Whathappensinstead • Not subjected to a YAGNI check • Rarely tested • Rarely refactored • Often broken by refactoring!
- 12. Whathappensinstead • Rarely demoed • Feedback gathered rarely and haphazardly • Rarely updated • Almost never decommissioned properly
- 14. ARecipeForDisaster • Logging operations doesn’t want • Missing logging operations does want • Not capturing the right information • Not making the system more reliable • Not making the system easier to manage
- 15. CopingMechanisms • Operations tries to: • Sift through what’s there • Do detective work to figure out what’s there • Add some scripts • Or re-engineer something
- 16. ARecipeForDisaster And sometimes, just actual disasters
- 17. “ThrowitovertheWall” • This situation is toxic • Operations puts up “release gates” • Devs resent operations • Spiral of mistrust, or worse
- 18. WhatWorksBetter? • Collaboration, not negotiation • Developers want this too • Some just don’t know it yet
- 19. ButHow?
- 20. TreatOperationsasUsers • And not just any users, either • Possibly the most important users • The operations team are the users that turnyourapplicationon
- 21. MorethanJustPrioritisation • This should be about story acceptance • Writing the stories in the first place • Testing the stories • Demoing the stories • Deciding the stories are done
- 24. After • “Log on application startup” • “Log on an uncaught exception” • “Log when an import job completes”
- 25. ARealExampleStory “As operations, I want a log entry to be written when the application starts, so that I can determine how often this happens over a period of time”
- 26. Very,Very,Different This process changed how I thought about logging entirely
- 28. Weusetools… • Designed for the wrong customer • Designed with the wrong features • Designed to do the wrong things
- 30. TheWrongFeatures • Conditional Logging • Log rotation • Configurable destinations • Dozens of output formats
- 31. TheWrongFeatures • ConditionalLogging • Log rotation • Configurable destinations • Dozens of output formats
- 33. TheWrongFeatures • Conditional Logging • Logrotation • Configurable destinations • Dozens of output formats
- 34. TheWrongFeatures • Conditional Logging • Log rotation • Configurabledestinations • Dozens of output formats
- 35. TheWrongFeatures • Conditional Logging • Log rotation • Configurable destinations • Dozensofoutputformats
- 36. Notdeveloperfriendlyeither • Separate configuration • Not IoC/DI friendly • Not test friendly • Not refactor friendly
- 37. FeaturesWeActuallyWant • Provide a list of log messages • Handle stack traces properly • Make it easy to parse log messages • Make it easy to search for log messages
- 39. EnumBasedLogging
- 40. EnumBasedLogging • An enum of all log messages
- 41. EnumBasedLogging • An enum of all log messages • Each enum value has a unique code
- 42. EnumBasedLogging • An enum of all log messages • Each enum value has a unique code • Each enum value has a format string
- 43. EnumBasedLogging • An enum of all log messages • Each enum value has a unique code • Each enum value has a format string • To log: provide an enum value and format string arguments
- 45. CodeSample
- 46. OpenSource
- 47. TheLibrary • Open source (Apache2) • Opinionated • Simple output, easy to read, easy to parse • Small, simple, no transitive dependencies • Java 8 required
- 48. TestabilityFeatures • Designed for testability • Special test double • Mock framework agnostic • Contract tests for your enums • OpsLogger instances always use injection
- 49. UniqueFeatures • Can automatically generate documentation • Logrotate friendly • Easy to parse with logstash • Special stack trace handling
- 51. PartingThoughts • There are no non-functional requirements • Operators are users • Be involved in the acceptance process • Foster collaboration, not negotiation • A lot has changed in 15 years • Don’t let developers think Ops is exactly like Dev
- 52. Thanks!