. . . and libyears to go before I sleep

     

A link to this idea appeared in my feed. I have noticed most people gravitate towards single-number summaries such as (shudder) arithmetic mean so the idea does have some merit.  And, the measurement is very easy to drop into any set of repositories.

Apologies to Robert Frost for the title.

The woods are lovely, dark and deep,  
But I have promises to keep,  
And miles to go before I sleep,  
And miles to go before I sleep.

Complexity & Chaos, cause Crushing Complications

Do you remember when our production systems were less-complicated and easier to debug?  Production Issues were easy to diagnose and it was always faster to recover.  I remember writing an application in a single page of HTML that used server-side include directives in the web server.  The entire application (order form, order acknowledgment receipt, order processing)  is 200 lines of HTML, 4.6KB. Sigh. Pete Hodgeson at Honeycomb wrote an interesting analysis of the giant leaps backwards we have made in the last 25 years because we have piled on so much unneeded complexity in our systems.  Someday I may create a conspiracy theory based on the cui bono (who profits) from this ridiculous inefficiency.  I recommend browsing through Hodgeson's article but not my HTML code or my article.

Wakers by Orson Scott Card

The master still has great stories left to tell.  I enjoyed this one; the ending was somewhat abrupt; 5/5 Stars.

Upgrade by Blake Crouch

I enjoyed this one.  It's a fun thriller with a fantastic wish-fulfillment magic system worthy of the Marvel universe.  5/5 Stars.

Backups are much worse than useless

In information technology (IT) and software engineering, operators and DevOps folk define their "backup" systems and policies.  However, they infrequently or never state their data restoration service levels.  The only measurement that an end-user cares about is: how quickly, and from which times in the past, can you successfully recover the state of my data?  And, if no data restores are needed, how do you test that your recovery service levels are met or exceeded as my data volume grows?

Making many copies (backups) of data frequently and storing all of those copies (or differences) costs a significant amount of network, compute, and storage, especially for longer retention periods.  Therefore, the IT or DevOps team should discover and deliver only the restoration requirements their end-users need, and for which they are willing to pay or be cost-allocated.

We are in the recovery business, not the "backup" business.  I consider the term "backup" to be a terrible word because it normally means only "untested, expensive copy."  Therefore, I personally never use that word and instead talk about our recovery capabilities and service levels.  And I always try to implement an automated test system that verifies these data restoration service levels are correct.

Alerts & alerting again

Dan Ravenstone published a refresher on Alerting that's worth a quick listen or skim.  Alerts are supposed to help us improve a service by enabling us to detect issues affecting our customers sooner and should also be useful to help us diagnose the issue quickly so that the issue can be mitigated, alleviating customer pain.  Most alerts are false positives -- paging us out of bed for a problem that does not exist.  Other alerts have no information about what is causing the issue, just some vague alarm that something is wrong.  And, of course, the absence of alerts is the most frequent reason customers tell us when our service is not working instead of our alerting system.

3Zekiel by Peter Cawdron

The science & magic system are not very good but I liked the characters. 3/5 Stars.

Hitch Hiker & Hotshot by Peter Watts

I enjoy Peter Watts' "Sunflower" universe; Watts publishes some short fiction on his web site and the fan site, so I read a novella and a few stories.   These two are good, worth reading, 4/5 Stars.

Axis Crossing by S. H. Jucha

The conceptual setting and "world building" framework makes for a very compelling space opera.  Far-flung, disconnected civilizations in star systems separated by vast oceans of time and distances are brought back together after millenia with wildly disparate cultures & tech.  Unfortunately, the author's story telling, characters, motivations, and the background tech are not great. 3/5 Stars.

Vanity and other Metrics that measure the wrong thing

John Cutter has a new piece out about vanity metrics that's worth skimming.  It's a reminder that our cognitive biases and need to boast, brag, and make ourselves look great to "management" can be destructive to our mission and purpose as an enterprise.  I have encountered more subtle cognitive biases where our metrics and goals in a business-to-business setting are focused on the use of our free software service instead of the purpose for which our free service is intended.  Folks are using our software, yes.  But are they getting our joint mission and purpose done better and more efficiently?  Software is our means to an end.  Customer success is literally our success.  Therefore, even if our customers love our software and love using it, if alternatives to our software are better or more efficient, both our customers and we have failed.  Focus on what matters.