Opslogger: Operations code (should be) production quality too!
3 likes519 views
The document discusses the importance of considering operations teams as key users in the software development process, especially regarding logging practices, which are often poorly managed. It outlines the flaws in current logging systems and proposes a new approach through the 'opslogger' library, designed specifically to meet operational needs. The emphasis is on improving collaboration between developers and operations for better software functionality and maintainability.
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!