SRE Workbook Notes

A few items I found insightful, outside of an overall great book:

• Automate This Year’s Job Away
• VALET Dashboard – like the ideas.
• Using VALET in Testing
• Testing Alerting Logic
• Identify and Measure Toil
• Zombie Code Slayer badge
• Main Roles in Incident Response
• Gamification
• Jsonnet – Configuration language
• Release Engineering Principles
• Production Readiness Review
• SRE Practices Without SREs – Start TODAY!

Engineering Company = Engineering Culture

Great article on Wall St vs New Order/Startup companies.  One particular statement stands out:

Engineering Company = Engineering Culture
In Wall Street, Finance is the business, and technology is merely a mechanism that exists to facilitate that business. Technology is seen as a cost center, and when it is necessary to cut costs

SRE Post Mortem Gamification

I really like gamification.  In some firms its in almost part of the culture.  Of particular interest around post mortem’s is Google’s gamification leaderboard.

Some individuals are incentivized by a sense of accomplishment and progress toward a larger goal, such as fixing system weaknesses and increasing reliability. For these individuals, a scoreboard or burndown of postmortem action items can be an incentive. At Google, we hold “FixIt” weeks twice a year. SREs who close the most postmortem action items receive small tokens of appreciation and (of course) bragging rights

Cyber Security – Notes

A few weeks ago, the Sunday Times included a CyberSecurity supplement, available online here.  What follows are a few interested pointers:

• Human Centered Security
• Phishing attempts is number one in terms of insider threat
• Increase in awareness and training can lead to the biggest improvement in security
• Cloud – understand where your sensitive data is, assess access and sharing privileges.
• Open source vulnerabilities create serious risks.

DevSecOps – Secure Code

Worth a listen, Max Saltonstall and Justin McCarthy are joined by Johnathan Hunt, VP of Information Security at InVision to talk about pen testing, bug bounty programs, and secure code.

• Pen Testing yearly cycle – “significant flaw in thinking”
• “static analysis scanner that sits locally on all software engineers laptops, every piece of code every line of code that they write their supposed to scan this prior to committing that to the repos. Once it’s in the repos, once we get ready to deploy and merge in a master at that point that runs again, right, the same tool runs within a CI CD pipeline, after we’re doing, QA testing, and all these other things that run also is an automated tool set, it runs again, at that point, it notifies us or notifies them right of vulnerabilities resident, now we can choose to block that we can choose to say, hey, if it’s a critical vulnerability, or a high severity vulnerability, we’re going to disable or block the push right to production”

Software Productivity

First up, and worth a read/watch is “How Is Software Developed At Amazon?”.  Of note:

• Automate anything manual
• DevSecOps

Following closely are the many references called out in QA Financial keynote from Jordan Daniel, Head of Testing and Enterprise Release Management, Bank of England:

• Boehm, B. W. (1987) Improving Software Productivity
• Grady, R. B. (1992) Practical Software Metrics for Project Management and Process Improvement, 1st Edition Prentice Hall.
• Henderson, P. (2006) Why Large IT Projects Fail.
• Jones, T. C. (2012) Software Defect Origins and Removal Methods. Draft 5.0. p. 3.
• McConnell, S. (1996) Software Quality at Top Speed.
• McConnell, S. (1996) Rapid Development: Taming Wild Software Schedules. Microsoft Press
• McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction, 2nd Edition Microsoft Press
• Medina, L., Liedke, R. (2015) Defect Prevention Using Agile Techniques.
• Patton, R. (2005) Software Testing. 2nd Edition Sams Publishing
• Suma. V., Gopalakrishnan Nair, T. R. (2008) Effective Defect Prevention Approach in Software Process for Achieving Better Quality Levels.

DevSecOps

Another day, another buzzword – DevSecOps.  Like most buzzwords, the devil is in the detail 🙂  In this particular case its a continued refinement and improvement of the DevOps tool chain, that correlates well to Accelerate capabilities, with evidencing through metrics:

• Deployment frequency
• Lead time
• Test coverage
• Detection of threats, security defects, and flaws
• Mean time to repair
• Mean time to recovery

You may also want to include Rotate, Repair, Repave into your practices as well when considering the Open Source library language flaws.

 

Fighting Cyber Vulnerability

This video on DiffBlue Secure offers interesting insight into how using the right tool, at the right time as part of the SDLC tool chain, could reduce the defects and incident management overhead.  Hopefully this would result in a decisive “Strict prioritisation” graph.  Food for thought

Avoiding the Build Breakers with DiffBlue

ABN Amro provides insight into its Continuous Integration Continuous Delivery (CICD), tooling, software quality and security via this posting.  Of interest is how they have partly improved quality via “Build Breakers”.  The issue with these breakers is that its fine for new projects who are clear on the bar, but older projects have somewhat of a hurdle to jump before they can adhere to the break.

Solution?  DiffBlue

How?  If you added DiffBlue to the CI/CD pipeline, in the event that your project drops below the % code coverage breaker, DiffBlue could create the Unit Tests, bringing you quickly back above the breaker.

Moving aged projects/products into your nice shiny CI/CD pipeline could also be aided by DiffBlue.  Generate a “full regression suite” before migrating into the CI/CD pipeline.  Problem solved.  Migration is now part of the build breaker quality solution without the need to hire personnel 🙂

Finally, Accelerate provides a view on the capabilities required to 2x team/product delivery.  DiffBlue is part of the solution for Capacity 4, Test Automation.  DORA State of DevOps also play to DiffBlue, with regards to Elite/Higher performers undertaking considerably less manual testing than Medium/Low performers.

Stop Writing Unit Test – Use the Force

If you’re still spending time writing unit tests, or finding hitting the mandated code coverage bar (e.g. 80%) is difficult, consider BlueDiff.  The Force in this instance is AI for Code.  Documentation available here.

Demo available here