If you build it, someone has to monitor it. In most companies, that person is a bit on the bitter side, standing like Gandalf on the causeway to your greatest software achievement to date, screaming ”You shall not pass” in futility.
It doesn’t have to be this way; it shouldn’t be dev vs. ops. You just need to build stuff that doesn’t make the code monitor’s life miserable. Consider the ops team as one of your customers, and make software that it can use. Make life livable for the people working downstream from you.
Here are ten ways you can help the code monitor, and ops in general, help you.
Follow agreed-upon standards
If the structure of the software is familiar, you’ll encounter less resistance. So, write up and follow a set of standards around what technologies are used, how they’re used, and the overall “shape” of your software.
Don’t sneak through something major
You wanted to use a document database instead of good ol’ (sn)Or(e)acle? So you stuck JsonDB or Nitrite in your software. But did you lay that out in the right place on disk? Naw. Is it getting backed up or replicated properly? Naw. Is it even highly available in the way you set things up? Naw. So, it isn’t any wonder the code monitor hate you.
Getting in the right piece of infrastructure that supports business and technical requirements may mean putting some of your dreams on hold. You may also have to make the case for it. However, it will save you from being told to rip that sucker out or from getting fired when an unforeseen infrastructure issue results in data loss.
Establish a regular review process
“Gandalf” shouldn’t be able to reject things arbitrarily. There should be review process based on the agreed upon set of standards for what goes in the software and what process is followed in QA and deployment. If your organization doesn’t have one, establish one.
Qualify changes. In your release notes, installation guide and wherever appropriate, qualify changes. Don’t just put “Changed JSON serialization code.” Add “This is a very minor bug fix, no dependencies or infrastructure are affected.”
Expose APIs (securely)
Rather than having to unravel some kind of Zip file or assembly to turn something off or on, or to make some configuration change, expose an API. Make your software easily manageable.
That said, don’t do this in the clear over port 80. Follow good security standards.
Expose metrics
In those APIs, expose metrics. Make it possible to monitor your software. Track things like requests per second, financial transactions per day, or performance metrics. Collaborate with the ops team to figure out what is worth monitoring.
Support a monitoring tool
Ensure those APIs support the ops team’s monitoring tool. Maybe ops uses Nagios. Hopefully, it’s not stuck on some ancient version of HP OpenView (the most likely scenario in some larger companies).
Standardize installation
Make every version follow a similar installation pattern where possible. Ideally, make that scriptable or in a standard assembly (that is, “copy this .war file here”).
Publish a migration guide
Database changes and other structural changes happen from time to time. As you change things in dev and test, document such changes and explain what you did and why. Produce a step-by-step migration guide explaining to ops what it has to do and why. If possible, produce scripts that are easily reproducible.
Be humble
Developer egos annoy everyone. Instead, go in asking how you can help make sure the software is manageable, monitorable, and installable.
Also, no one cares if it works on your machine or not!