Showing posts from May, 2017

Rugged DevOps

Rugged DevOps is a method that includes security practices as early in the continuous delivery pipeline as possible to increase cybersecurity, speed and quality of releases beyond what current DevOps practices can yield alone. (1) “Rugged “describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure and resilient software. (2)
As business increasingly relies on agile software development, the absence of matching fast-moving security methodologies in the delivery pipeline will essentially increase the risk of a security breach or a cyberattack. Security staff must be imbedded into cross functional teams to ensure a more sustainable and less risky continuous deployment value chain (continuous integration, continuous delivery and continuous testing). The bad guys have already acquired these skills and the use of automation to engage in a continuous attack on our defenses.
Security was named as the …

KPIs and SLAs

A short while ago I was asked this question from one of our reader: “I want to set a KPI around how much of the time we meet the SLA. Like 'meeting the SLA x% of the time'. Can someone advise what would be that 'x'? What is the common practice?  Is there an industry standard around this?” I’m going to have to go with the consultant answer and say it depends.   First, are we talking about a single service to a single customer? Are we talking about multiple services to multiple customers or somewhere in between those two extremes?
Your SLAs should include details of the anticipated performance that your customer expects.  First thing you need to do is discuss with your customer what are the levels of utility and warranty they are expecting? Then document and agree these targets are reachable given the resources that are at your disposal and any constraints that may be discovered. The requirements for functionality (utility) should be defined by your BRM process and docum…

Site Reliability Engineering

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.”
Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ((formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt.
The discipline of SRE can begin to reduce this dilemma by introducing multip…

What’s New in IT?

What isn’t? With the internet of things there are so many options available to consumers that were not available even one month or one week ago.   With technology and job role functions evolving so fast, the best way to stay current is to become educated.  Here are just a few bits of interesting information.
New for Every Day Consumers: In a recent update Google’s Virtual Globe has introduced a feature called "Voyager." No longer will you be limited to only exploring places you've heard about, nor will you have to resort to randomly clicking on areas of the planet in hopes of finding a gem. Instead, "Voyager" presents you with dozens of curated journeys around the globe. Each voyage is centered around a theme. “Museums Around the World” will take you to a Street View of museums in every corner of the globe. If natural formations are more your speed, "Earth View" will show you "the most striking and enigmatic landscapes available in Google Earth.&q…

Search This Blog