DevOps 成功并非总是数字上升_AI阅读总结 — 包阅AI

Story time! In a past life, I worked briefly in knowledge management. There I maintained the content the organization hoped would help internal customers help themselves.

The organization never had a proper knowledge base before, previously storing all technical support documentation in countless PDFs that hadn’t seen updates in years. Just before I started, all that content — outdated and in many cases useless — was copied and pasted, unchanged, into the new knowledge base.

The horror.

But that wasn’t the only terrifying experience in those first few days. Further jump scares would come in a meeting with management, where we discussed what success would look like for our small, newly formed team.

“How long does it take to write a knowledge article?” was the first chilling question, as if “one article” could be a quantifiable measurement. Web pages differ in length, of course, and the time needed for each page depends on the subject’s depth or complexity.

The real horror set in, however, when I realized the manager’s only vision of success for the new knowledge base was how many articles we could add per week.

Content for the sake of content is rarely useful, but to reiterate, our starting point was over a decade’s worth of old PDFs uncritically pasted into a system unsuited for the format.

The pages that were still relevant needed hefty rewrites because they could not be found in search or were not written with accessibility in mind. Many weren’t suited for a nontechnical audience, which was, bluntly, almost our entire audience.

To make the knowledge base useful at all, much of our work would involve reducing the amount of content through rewrites, merges and by deleting pages no longer relevant.

The reality that success could actually mean reducing page numbers broke brains because “numbers must go up” was the only metric that made sense to those I was reporting to. More is always better; everyone knows that!

Due to that mentality, I was often discouraged from making content useful, which meant people wouldn’t always get the help they needed even if they could find it.

So, if help content isn’t findable or understandable … why even have a knowledge base?

But, hey, for those reporting upward, everything was all dandy: “My team is performing because, look, numbers go up!”

Some of these conflicts point to a systemic culture problem that highlights how badly things can get compartmentalized when teams don’t share goals. More importantly, it also shows how easy it is to lose sight of what success and value actually are when your ideas for both are so few, narrow and isolated.

In this anecdotal case, there was no way to prove the obvious — that the same information but easier to read and find could lighten the load for other support areas — because there was no mechanism to draw the correlation. Information sources that might’ve allowed us to find connections between content and customer behavior were, bizarrely, kept at arm’s length.

The lesson here is that by focusing so much on “numbers go up” without understanding what those numbers mean in the broader context, it’s easy to miss the relational effects that measured activities can have on one another. You only obscure areas where you might find new benefits.

Thankfully, for those of us in the software development space, ideologies like continuous delivery and DevOps help you build this visibility into your system. Strong monitoring and observability are core recommended practices in both.

As per the Octopus white paper “The Importance of Continuous Delivery,” for example, continuous delivery recommends not only tracking every data source, but doing so in one system so you can see relationships not otherwise obvious. It also suggests tracking business metrics in the same system as your technical metrics to see when a technical change has a negative or positive impact on business or vice versa.

Crunching the Numbers (Derogatory)

Look, I understand it’s natural in business that some numbers must go up. Organizations want to see profit margins rise, of course. Likewise, software teams adopting DevOps should strive for more commits, builds and deployments because those are proven predictors of organizational success.

However, to use “numbers going up” as your only measurement for success across all tasks is to deny yourself complete understanding of what value means across your business. Sometimes it’s smarter to do less in one area so you can do more elsewhere, and you won’t find the balance or spot where you need to adjust if you build walls between your information.

Only by maximizing the benefits of available information can you make those calls with confidence. Context is king, and it’s context you’ll miss if you don’t understand relationships in your data.