I started my technology writing journey with a 2 part blog (One & Two) on Service Delivery Excellence, before jumping into the DEVOPS bandwagon, but now as I read across all related discussions, I end up feeling that the good kid is always the DEV and OPS are the unnecessary tag along.

We always talk about how the end goal is to make quicker releases, fixated towards adding value with continuous deployments, insinuating that OPS is the roadblock towards that goal, or that collaboration is the name of the game, and OPS should stop being confrontational, etc, etc.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

Today, I am on the other side of the fence and will sit on judgment on the question of if any changes are needed at all for the OPS teams to engage themselves into the DEVOPS culture.

The lifecycle framework, defined by ITIL, COBIT or MOF (looking at the ‘Microsoft Operations Framework’ with renewed interest after my initial days of GRC stint) is quite similar across all phases of IT Service Delivery and consistent with the DEVOPS principles of stable, scalable, lean and quicker delivery of value to the user community.

ITSM’s broadly references

• Focus on services rather than systems
• Process oriented management approach
• Continual Improvement as part of their Deliver, Support and Operate lifecycle,

Then, the questions arise:

• Does the Service Delivery Framework (SDF) changes?
• Do we have to revisit the 3P’s (policies, processes & procedures) which are working well, as we move on to align ourselves with DEVOPS?

Historically in almost all large organizations, Operations [OPS] has always worked in silo, minimal trust of the development & testing teams to deliver a high quality change with a very suspicious view of all changes, as understandably they are responsible for the stability and maximizing availability of the Production environment with a consistent user experience.

On the other hand Developers [DEV] are under greater stress to deliver features and fix defects at a much faster pace due to many reasons. Shorter coding windows, cutting corners on testing cycles, deferring performance/ regression issues ( yes it happens!), and of course your team’s efforts are not just measured but the survival depends on the count of production runs rather than on quality, innovation or improvements.

“Throwing a dead cat over the wall” is how someone wrote of the handover of new code to OPS, I wouldn’t agree with that analogy, as OPS will at least expect it to land on three legs, a DOA would be thrown back with the same impunity!

The business value, Operations add in terms of availability and support to the customer far exceeds the risk of adding half-baked features in the ‘need for speed’. On the other hand it’s also imperative that we work towards a goal of a collaborative approach to a stable, sustainable and faster delivery of features to remain competitive.

I define DEVOPS as “combining a right mix of interdependent variables like People, Process and tools for fast and quality software delivery”, and Operations contribution towards this effort spans across all the variables adding immense value towards a successful initiative, with new insight of the challenges and shared concerns in improving the processes and delivering better software.

DEVOPS is not just about creating scalable infrastructure on the fly, or implement newer tools for rapid and automated deployments, or even about creating a SWAT response around monitoring. It is equally about envisaging a collaborative model, ensconced in proven principles and practices in order to add business value by delivering quality software rapidly.

So, what should OPS do differently to be an effective contributor of the DEVOPS team?

To start with, OPS should grab the advantage of being involved at the outset of the planned lifecycle by contributing with constructive inputs and using their expertise in:

• Assessing Infrastructure impact and capacity review.
• Influence design decisions & operational needs.
• Review all Service commitments and SLA’s
• Security and entitlement management
• Highlight any potential changes to operational procedures.
• Update monitoring and alert mechanisms
• Improve automation.
• Upgrade run-books; training of the service desk, share knowledge.

OPS also can keep a strict overview in the issues faced during the deployment/testing journey of the release and measure it against their own operational readiness thresholds.

The best outcome of this collaboration, in my opinion is that there will be no need for a ‘Warranty’ or ‘Initial support’ period by the DEV teams. OPS will be fully aware of the journey and has partnered to ensure the ‘Cat’ has passed the minimum health checkup and also is fully aligned with the changes to the support model from day one.

In fact the ‘Cat’ will no more be chucked over the wall, rather will formally pass through immigration!

Thank you for the time.

Visit my blog http://askhurram.com/

 Read On, Live On.