Sunday, July 31, 2022

. . . 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.


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.


Saturday, July 30, 2022

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.

Friday, July 29, 2022

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.


Sunday, July 24, 2022

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.

Friday, July 22, 2022

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.

Monday, July 4, 2022

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.

InfoSec map is not the Info-Threat territory


We have many recent reminders of the growing, irrational gap between real information security threats and the solutions, regulations, practices, mitigations, and technologies we can and should bring to bear to mitigate these threats.  The recent successes and growth of ransomware is one indicator that malware threat mitigation is obviously failing.  Personally, I would like to enlist everyone to protect themselves and "crowdsource" aspects of the problem.

Within the Information Security attack / defend landscape, attackers have all possible advantages, including "asymmetric warfare," where a single attacker can easily harm billions of people. Attackers have enormous wealth and resources to create attacks as they are funded and resourced by nation states, wealthy organized criminals, and professionals.  For decades, governing entities, regulators, & consortia have written standards, regulations and policies that chase after emerging "cyber" threats, and the trillion-dollar tech giants have tried to protect their own customers by developing anti-malware prevention, defenses, as well as mitigation hardware and software.
 
 # 

A wise mentor once told me "Policy is hard.  Technology is easy."  This wisdom is broadly applicable in many areas of software development and IT: Naming Policy, Data Governance Policies, Algorithm Selection, Object Factoring, and even Design Policy.  

One recurring problem I have encountered is the ubiquitous confusion in Information Technology of an abstract requirement, problem, threat, or need versus one or more technological solutions (software products) that try to meet the requirement or solve the problem.  IT professionals get caught up in the solution and see their own problems through the lens of some product or product family.  It is nearly impossible for me to convince them to separate clearly the probability of a successful attack, the true severity of such an attack, and the resultant risk for our organization. Instead they see our problem through the lens of some specific IT technology that is designed for some other customer in some other situation to mitigate that other organization's risk.  This issue is much worse in an organization where estimates of probability multiplied by the severity (risk) varies enormously among the organization's stakeholders and decision makers.  After my repeated attempts to help InfoSec folks write artifacts that separate threats from technologies, they always inject some product and some mitigation to risks we do not have and I never prevent it.

So, I plan to "democratize" and crowd source threat mitigation wherever I can.

I shall enlist and empower everyone to help mitigate cyber threats.  One method is illustrated by the entire lifecycle of the Russian military's attack on Space-X Starlink consumer internet service in Ukraine. The approach Space-X's took to reacting to the problem is instructional and generalizable. They created, and shipped a mitigation very quickly. But most-importantly the shift in attitude from the USA's department of defense on the attack / defend methods will eventually broaden how nation states and large companies help defend us. When Starlink was jammed in Ukraine, Space-X reacted by calling the issue a "free QA department" that found a bug for Starlink to fix.  All of us can take this idea to heart.  We should all consider email spam, phishing, ransomware, click bait, and cyber attacks we encounter as training to make us "antifragile" and resistant to more-dangerous and better attacks we shall encounter in the future.  The US DoD said that our current checklist-driven approaches are flawed and we must be much more proactive in formulating defense.  Education, training, and constant vigilance among everyone is a step in that direction.








The 5 Dysfunctions of an engineering team

Management concepts like this one deserve frequent reminders. Thank you, Michael, for blogging the link and sharing your own thoughts.  Organizations in which I have been a member fall into these patterns of failure from time to time, so recording a reminder here will be useful. The original book when it came out was great and the sequel, "overcoming the 5 dysfunctions of a team" was a great refresher.

 # 

On a somewhat related note, another set of authors and books worthy of frequent reminders are the Crucial Conversations team who also wrote Influencer. Don't fall into the "serenity trap."

Sunday, July 3, 2022

Systems Administration & Ops IT is not DevOps


I love rants like this one.  All of the points the author makes are well-taken.  Just as we re-labeled manual testing "software test engineering" or "quality assurance," so too are we now calling systems administration and data center operations "DevOps," as though the label itself will reap the benefits of true software development and maintenance for better operability.



Breaking News von Frank Schätzing


Ich bin sehr enttäuscht, weil Schätzing gut schreibt. Die Handlungsstränge und die Story sind gut ausgearbeitet. Das Buch hat mehrere fatale Mängel: Es gibt keine arabischen Schriftzeichen. Alle berühmten Persönlichkeiten haben deutsche Werte, Kultur und Politik. Das Buch ist historisch ungenau. 1/5 Sterne.