DevOps and support organization

Question

Nowadays companies go into devops practices to boost productivity.

In our case we (3rd party outsourcing vendor) developed a first version of the product for our client , it’s cloud based platform. We do have tests, the deployment is semi-automated since there are fashion manual steps (like AD requests) . We don’t have continuous delivery and deployment yet, though. During development, we cooperated with client IT ops so they contributed to the product development (they built images, deployed to pre-prod, prod, fixed issues related to client infrastructure)

Now it’s time to go-live and client wants to formalize support but still follow devops practices.

For me it’s quite hard to understand how this can be built.

For example: If we keep on implementing new features and have a team working on the product, we can spend % of development time on support requests (2 and 3rd level of support), so that devs are integrated into ops, and understand the pain of users or ops, can not only fix issues but also bring some improvements to deployment, monitoring etc. to make product more reliable, faster and deliver value to business quicker.

But what if there is no new features development and just support (with 2nd and 3rd level) that either configuration and standard operations according to runbook (2nd level) or defects fixing on 3rd level. Since those are OPEX for clients they don’t tend to invest in this – hence there is no real opportunity (in terms of efforts spent) to follow and foster good devops practices during just support with no active development.

What do you think ? Is it possible to run support in devops mode with no active product development ? how this can be done ?

Answer 1

DevOps for Lifecycle Management

Support, maintenance, and other aspects of service management don't generally seem like ideal candidates for DevOps practices. Service management in general is often more about defining service level agreements than about iterative processes or validated learning.

With that said, continuous process improvement, automation (especially infrastructure-as-code), and practices that improve your break/fix and patch cycles are all useful DevOps practices with calculable business value. Without sufficient DevOps infrastructure, tools, principles, and practices, companies generally find that supporting a system gets harder over time.

Every non-DevOps patch or tweak adds cruft and drift to your system, and the technical debt will pile up. Whether it makes business sense to allocate resources to improving long-term sustainability of your systems is a decision your senior management must make.

As a practical matter, and from a real-world engineering and program management viewpoint, the answer is generally that it does make sense to follow DevOps principles throughout the system lifecycle. However, circumstances may vary.