SRE Workbook Notes

•April 21, 2019 • Leave a Comment

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

Engineering Company = Engineering Culture

•April 14, 2019 • Leave a Comment

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

•April 8, 2019 • Leave a Comment

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

•April 5, 2019 • Leave a Comment

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

•March 22, 2019 • Leave a Comment

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

•March 4, 2019 • Leave a Comment

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

•February 24, 2019 • Leave a Comment

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.