Turn any signal into insight and action. See how PagerDuty Digital Operations Management Platform integrates machine data and human intelligence to improve visibility and agility across organizations.
Connect insights to real-time action by aligning teams through the shared language of business impact.
Check out the latest products we’ve been working on—including event intelligence, machine learning, response automation, on-call, analytics, operations health management, integrations, and more.
Digital Operations Management arms organizations with the insights needed to turn data into opportunity across every operational use case, from DevOps, ITOps, Security, Support, and beyond.
Over 300 Integrations
Discover DevOps best practices with our library of webinars, whitepapers, reports, and much more.
Learn best practices and get support help with resources from our award-winning support team.
See how PagerDuty works with our live product demo — twice a week, every week.
We've created a maturity model to assist on the journey to digital operations excellence. Take our short assessment to find out where your team falls!
Interactive, simple-to-use API and technical documentation enables users to easily try updates and extend PagerDuty.
Engage with users and PagerDuty experts from our global community of 200k+ users. Become a member, connect, and share insights for success.
Get all your PagerDuty-related questions answered by exploring our in-depth support documentation and community forums.
Using Data to Dismantle a Criminal Industry Human trafficking is a $150 billion dollar criminal industry that denies freedom to over 40 million people globally—and...
PagerDuty helps organizations transform their digital operations. Learn more about PagerDuty's mission and what we do.
Meet our experienced and passionate executive team.
We are risk-taking innovators dedicated to delivering amazing products and delighting customers. Join us and do the best work of your career.
With the PagerDuty Foundation, we are committed to doing our part in giving back to the community.
Is there such a thing as enterprise DevOps? You bet.
After all, at the end of the day, DevOps is simply a methodology — one that enables faster, more efficient, and higher-quality software releases, which are all good things whether you’re a startup with three employees or an enterprise with 3,000.
And that’s why DevOps is for everyone — especially today when DevOps has reached maturity. Let me explain…
We are at the maturity phases of DevOps adoption. While bleeding edge practices around microservices, Kubernetes, etc., steal the show, the 3+ years-old core concepts of DevOps are mature, and there is tremendous adoption. However, there is still some opposition. And it comes from all sides of the house — Security, Development, Operations, and Testing, each with their own flavor of distaste. Security believes going faster is going to create more vulnerabilities. For Development, it may not be streamlined enough (i.e. Operations still exists). For Operations, there is a fear of loss of control; and for Testing, testing for things like security faster usually means more issues to have to deal with.
Not only do some folks from these functions still harbor hesitation over DevOps, but they also operate in an enterprise, where the concerns are accompanied by the enterprise’s inability to make changes at the same rate of startups.
The problem is that there is some ambiguity in terms of what DevOps actually is. And that is because there are two DevOps. First, there is DevOps the function. The function is pretty clearly defined as the people who generally report to Operations, but serve developers to build and maintain delivery chains, and provide infrastructure. This definition does imply organizational structures, and it is much easier to argue that this function does not fit into existing structures than to argue that the broader DevOps definition does.
The second definition of DevOps is the practice which drives development — “drives” being the keyword. It is not an end. In fact, if a DevOps environment were to “complete” implementation, they would instantly be a non-DevOps environment. The reason is that if you practice DevOps, you are building an environment that can also easily adapt. Lack of adaptation was a core issue in waterfall-based development practices, so that eventually the delivery chain dictated the application versus the other way around (which is how it should be.) The DevOps journey never actually ends.
Opposition is the equivalent of saying we do not want to improve our processes or applications, which would not hold up to most organizations’ goals when it comes to application development. The term DevOps alone can be frustrating because there are so many acronyms out there, but the word serves one primary purpose. It allows us to have a conversation about DevOps without redefining it every time.
Next, we move on to the concern that has some merit and grounding in tactics — and that is the concern that DevOps environments expose the organization to more bugs and security exploits.
This seems intuitive for those who have years of experience in quality and security. However, the drive of DevOps is not to break processes, but rather to make them more efficient. In efficient environments, security and quality are actually easier to implement, and better.
To speak to the concerns of the security and testing professional that speed generally creates more issues, speed does not mean less testing or fewer considerations addressed. It is actually the opposite. In a DevOps delivery chain, there are generally more checks and balances, but they happen on computer time, not human time. Thus, those checks and balances are faster, more accurate, and repeatable. So agility, in this case, can and should mean more secure and greater software quality, not less.
The best thing about DevOps the practice is that it does not assume organizational structure. It does not assume application structure, and it does not assume age or maturity of adoption. Organizations do not need to immediately have “two-pizza” development teams. They do not need to have container-based microservices applications, and they do not need to be one-year-old startups in Silicon Valley. And to address the greatest misnomer, developers suddenly do not necessarily need to be friends with Operations, or vice-versa. They just need to share the same goals.
Let’s take an extreme form of the most unlikely candidate for DevOps and see why DevOps is still useful. Let’s consider XYZ corp, a 10,000+ employee organization with a library of monolithic applications, and 100 developers supporting them. Most of the development is integration-based, where legacy custom code is a mystery to all. Projects are initiated by business units and driven by project managers and business analysts. Let’s say this hypothetical organization is in the construction industry and does not have commercial end users — certainly not technical ones.
Why would XYZ corp want to consider adopting DevOps best practices? For the same reasons they consider operational improvements everywhere: lower costs, and greater efficiency. While better user experiences and more frequent releases will end up benefiting them in a huge way, they cannot deny that streamlining development and making their application more effective for the user base won’t reduce the cost of creating the application, reduce the need to hire more employees, and solve more operations problems sooner. Projects will have more checkpoints for end users to validate what they asked for, which means that the risk of project failure is lower, and the spend on that project will be better utilized. Improved release velocity also boosts competitiveness as they’re better able to meet and exceed frequently changing customer expectations.
XYZ corp does not need to reformulate infrastructure the day after their embrace of DevOps. What they need to do is simply hunt for opportunities to automate, and treat application development as part of their core value versus a cost center. The reality is that even if XYZ is not facing the same pressures of quality applications today, it’s only a matter of time until they will. Eventually, technology will be such a part of their core business that better applications will be required.
You do not need to be a unicorn company or development team to embrace DevOps, because DevOps is the practice which drives greater efficiency of your operations and delivery chain, not the prescription on how to build it. The bleeding edge tools are there, and will always be there. But to embrace DevOps, you don’t need to use all of them. What you really need to do is focus on automation, quality, and the responsiveness of your software delivery chain.
A long time ago, back in the early days of 2017, we open-sourced our Incident Response Documentation, the reference point for all our internal processes...
Reflective Practice at PagerDuty With an almost 20-year career in social services—including working in institutions such as The University of Chicago, the United States Peace...
600 Townsend St., #200
San Francisco, CA 94103
905 King Street West, Suite 600
Toronto, ON, M6K 3G9, Canada
1416 NW 46th St., St. 301
Seattle, WA 98107
5 Martin Place
1 Fore St,
London EC2Y 9DT
© 2009 - 2018