devopsy.kinsta.cloud

Tag: ITSM

  • Machine Learning and ITSM: Helping Help Desks

    Machine Learning and ITSM: Helping Help Desks

    The field of machine learning is a hot topic. We know that this type of artificial intelligence (AI) provides computers with the ability to learn without being explicitly programmed. For people like me who need it in simpler terms, machine learning deals with systems that can learn from past data and experience to improve performance of a particular task.

    Machine learning already touches our lives, both personally and professionally, more than anyone could have imagined. For example, a lawn sprinkler system can be trained to tell the difference between squirrels and cats and to turn on when cats walk on the grass to shoo them away. Processing online search requests, filtering spam automatically out of our email inboxes and understanding and replying to our speech commands on smartphones are all machine-learning tasks being done on a daily basis.

    Sooner or later, machine learning will also be applied to IT service management (ITSM) to change the way help desks work. The benefits might include predicting issues and problems proactively, improving search capabilities and knowledge management, and classifying and routing issues with greater ease. To be more specific, you can expect the following scenarios in the near future:

    Service Requests Will Have Auto-Approvals and Custom Workflows

    With the implementation of machine learning, help desks can be trained to auto-approve service requests based on the employee’s role, department, work site and other parameters. For example, when a designer requests additional design tools or software, the help desk will be able to automatically approve the request and initiate a workflow without waiting for the manager’s approval. The help desk also can be trained to automatically check the workstation assigned to that designer for minimum system requirements to install the requested tools or software and create a request to upgrade the system, if necessary—all by itself.

    Help-desk systems will also be able to learn from past onboarding experiences and make suggestions such as the type of software and hardware the user needs, the access permissions they need based on their role or department, or even a printer configuration setup. These are all options for improving the speed of service delivered to end users.

    Level 1 Incidents Will Be Resolved Without Technicians

    End users will be able to search for solutions and resolve incidents without the involvement of any technicians. Through machine learning, help desks can be trained to scan incoming tickets and provide end users with solutions automatically, based on the system’s previous experience. Google Assistant-style chat boxes will also help end users resolve incidents or get information without even logging a ticket into the help desk.

    For example, a user would just have to ping the help desk that “the printer is not working,” and the help desk would be able to check the printer’s print threshold level and create a request for a toner replacement, if needed. The system also would be able to immediately and automatically send any relevant knowledge-base articles that might help the end user check network connectivity issues or reset the printer configurations in their machines.

    Help desks also could learn from past experience and data to route tickets or tasks to the appropriate technicians or support groups, thereby automating the ticket assignment process without having to create any rules or workflows. Machine learning would help reduce resolution times and improve the efficiency of the help desk team.

    Problems Will Be Anticipated and Prevented

    With machine learning, help desks will be able to analyze incident patterns and anticipate problems. In addition, trained help desks could automatically trigger notifications or create problem tickets for anticipated issues so that the help-desk technicians can investigate at the earliest. Say the performance of an application server starts deteriorating; help desks would be able to anticipate any application failures from the past performance data of that particular server, warn end users who might be affected, create a problem ticket and associate any relevant incident tickets with the problem ticket.

    Highly Dynamic Change Workflows Will Be Created

    Change implementations are always associated with a certain level of risk. Without a proper plan and workflow in place, change implementations can be costly. Help desks can learn from previous change implementation data and experience to help create highly dynamic workflows.

    For example, with the implementation of machine learning, help-desk systems might recognize potential signs of change implementation failure and prompt administrators to stop the implementation and execute the backout plan even before the failure occurs. Change management modules guided by machine learning will also be able to make recommendations during the planning phase based on previous experiences.

    Intelligence Will Impact Asset Life Cycle Management

    A sizeable number of incidents occur due to old IT assets whose performance has degraded. Machine learning can help automatically identify which assets might repetitively break down based on factors such as their performance levels and incidents associated with them. Once those assets are detected, the help desk can use machine learning to send notifications to technicians and facilitate ordering replacements. The simplest case could be the help desk automatically creating requests for printer toner replacements after a specific number of pages have been printed.

    ITSM is full of opportunities for machine learning. The scenarios above are some of the simplest use cases showing how machine learning can make life easier for both the help-desk team and end users. Though these might not be readily available as out-of-the-box solutions, they are not too far away into the future.

    About the Author / Ashwin Ram R

    Ashwin Ram R is an ITSM evangelist at ManageEngine, a division of Zoho Corp. He writes blogs, customer stories, and easy tips and tricks for the users of ServiceDesk Plus, the company’s IT help desk software. He has also authored the white paper, “The Handbook of Essential IT Service Desk Metrics.” He is interested in photography and is an avid collector of watches. Connect with him on Twitter and LinkedIn.

  • Site Reliability Engineering: How to Make the Operations Side of DevOps Actually Work

    Site Reliability Engineering: How to Make the Operations Side of DevOps Actually Work

    The DevOps movement often has been accused of focusing too much on the first half (Development) and not enough on the second half (Operations). Certainly there has been more attention paid to deployment of payloads than to operating running systems, leading to the dismissal of the handover between Dev and Ops as “throwing it over the wall.”.

    Lately, we have seen the emergence of a new focus on the stability and reliability of the systems that are the targets of those deployments, with the creation of the new practice of site reliability engineering (SRE). This has been a welcome addition to the IT toolbox, but it can still seem to put all the onus on Ops teams to catch whatever comes over the wall.

    The Problem with Site Reliability Engineering = IT Infrastructure

    In SRE, the IT infrastructure is expected to be highly automatic and self-healing in the face of any events. Here is the problem: That approach works well for foreseeable events, but less well for the unforeseen ones. Because of that factor, it works well in environments that run few types of individual workload types, but do so at very large scale. If you’re thinking that sounds like Google and Facebook, you’d be right.

    What this amounts to is massive engineering of the infrastructure to withstand known or foreseeable problems. However, typical enterprise IT environments are not like that. A large bank might have thousands of applications, each of which must accommodate changes on a pace that is dictated from outside the IT environment. Applying assumptions from one environment to the other is asking for trouble.

    To illustrate this, let’s look at an example from outside IT. Recently was the anniversary of the sinking of the Titanic, on April 15, 1912. The RMS Titanic itself embodies the principles of SRE, engineered to prevent or survive all manner of emergencies. The ship was equipped with state-of-the-art everything to transport its passengers in comfort and safety across the Atlantic.

    As we all know, that plan did not quite work out. A combination of unexpected changes in the environment (more icebergs than normal), business imperatives to maintain speed and mishandled warnings about the ice from other ships led the Titanic to disaster.

    While the consequences of an IT failure are rarely quite as dramatic as the sinking of an ocean liner, many of the same factors apply. IT administrators may believe that in the worst case their backups and disaster recovery plans will be sufficient to handle any problems, but these plans are designed around known and foreseeable problems. Unexpected circumstances can easily lead to cascading failures, which is why it is critical to be ready for the unexpected when it—inevitably— occurs.

    The Problem with Traditional IT Ops = Static Models

    The key flaw in IT Ops is reliance on static models of the world. These models come in many shapes – the CMDB is the “model” that many think of first, but static rulesets are also a model. The most dangerous models, though, are the ones that are invisible: namely, the filters that are put in place to determine which alerts and events are even worth considering.

    This is the flaw that ultimately sank the Titanic: The crew were unable to correctly priorities events and react to them in time to avoid failure. It is also the flaw that causes countless much more minor issues every day in data centers everywhere: the filesystem that filled up with logs, taking down the database that the critical business application relied on—and the filter that had not forwarded that alert because it usually was harmless. Or the loss of one leg of the redundant network link, which was ignored because the other leg was still up, so there was still a link—until that one failed too, and an entire site went dark.

    The key factor is that the filters were not wrong to suppress those alerts. By definition, informational or warning alerts are not the same as major or critical ones, and most of the time they can be safely ignored, to be dealt with later.

    Every now and then, though, a pattern of those alerts, if understood correctly, can identify a future problem in the making. These developing issues could be nipped in the bud, if only Ops teams had enough hours in the day to look at them and review them. But, of course, they don’t—every Ops team I have ever met is drowning in issues, and behind those there is a long and lengthening to-do list.

    What Can DevOps Do to Make Operations Better

    New approaches are emerging to make the principles behind SRE more widely accessible and applicable. In particular, more dynamic noise reduction and correlation is now possible, to sift those important alerts from the constant background noise and put them together into a picture of what is really happening. The key factor is to be able to do this in real-time and without a human having to plan out laboriously what are all the possible scenarios that they might need to know about in the future.

    Gartner has called this new approach Algorithmic IT Operations, or AIOps. The idea is to bring together all possible sources of events, whether those are alerts from the compute or network infrastructure, transaction slowdowns reported by an APM tool, automated deployments being run from a CI/CD toolchain, or anything else the might conceivably be relevant. All of this information then can be sifted by algorithms to understand what is actually important to Ops and brought to the attention of the right specialists who can work on the issues and get them solved fast. Part of that process is also the integration with systems of record (which generally means IT service management), and with automation and orchestration tools that can accelerate remediation activities.

    This is how we can get the Ops side of DevOps to where they need to be to be able to accommodate the ever-accelerating pace of change—whether from Dev teams wanting to run ever more frequent deployments, or from business users needing help with their own goals—or from the next unexpected issue to come down the line.

    — Dominic Wellington

  • ‘Big Bang’ DevOps: Posting from the Professor

    ‘Big Bang’ DevOps: Posting from the Professor

    I learned about The Diffusion of Innovation Theory in a DevOps Foundation training course. I wanted to get my DevOps certification, but more than that, to learn about what makes a DevOps initiative successful. When I mentioned the Diffusion of Innovation Theory to a coworker, he said, “It sounds like Sheldon talking to Raj on ‘The Big Bang Theory’ television series.”  Although the name sounds “Big Bang”-ish, the usage of this theory could be the real difference for success in any transformational change including DevOps.

    Let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in. DevOps is a culture shift.

    DevOps requires us to shatter the silos and to quickly integrate our teams to increase the flow of work from idea to end of life for the strategy, development, deployment and the sustaining of service over their life. Adoption of a new idea, behavior or product (i.e., innovation) does not happen simultaneously in a social system. It is a process whereby some people are more apt to adopt the innovation than others. Researchers have found that people who adopt an innovation early have different characteristics than people who adopt an innovation later. Learning what those characteristics are and then how to apply the proper technique for each will help with the management of organizational change.

    The Diffusion of Innovation is a theory that seeks to explain how, why and at what rate new ideas and technology spread. While most of the general population tends to fall in the middle categories, it is still necessary to understand the characteristics of a given target population.

    When promoting an innovation, there are different strategies used to appeal to the different adopter categories:

    • Innovators – want to be the first to try the innovation. They are venturesome and interested in new ideas. These people are very willing to take risks and are often the first to develop new ideas. Very little, if anything, needs to be done to appeal to this population.
    • Early Adopters – represent opinion leaders. They enjoy leadership roles and embrace change opportunities. They are already aware of the need to change and so are very comfortable adopting new ideas. Strategies to appeal to this population include how‐to manuals and information sheets on implementation. They do not need information to convince them to change.
    • Early Majority – rarely leaders, but they do adopt new ideas before the average person. That said, they typically need to see evidence that the innovation works before they are willing to adopt it. Strategies to appeal to this population include success stories and evidence of the innovation’s effectiveness.
    • Late Majority – skeptical of change and will only adopt an innovation after it has been tried by the majority. Strategies to appeal to this population include information on how many other people have tried the innovation and have adopted it successfully.
    • Laggards ‐ bound by tradition and very conservative. They are very skeptical of change and are the hardest group to bring on board. Strategies to appeal to this population include statistics, fear appeals and pressure from people in the other adopter groups.

    When promoting an innovation to a target population, it is important to understand the characteristics of the target population that will help or hinder adoption of the innovation. The Diffusion of Innovation Theory could be the “Big Bang” that you are looking for to ensure the success of your DevOps initiative.

    — Alice Acedia

  • Alerts Keep DevOps Teams Responsive, in Sync

    Alerts Keep DevOps Teams Responsive, in Sync

    Continuing our five-part series on “Continuous Monitoring: The Role of DevOps and APM,” this blog post will talk about how alert notification can help DevOps teams be more productive and agile.

    Amid the constant, rapid change and fluidity typical in DevOps organizations, there are some undeniable absolutes. These absolutes, present at each stage of the DevOps life cycle, demand your teams’ attention: A build or test succeeds or it fails; an outage of an app in production is restored to service or it lingers unavailable; users applaud or they blast out complaints. And with each of these states throughout the DevOps life cycle there are absolutes common at every step: Your team is either communicating or they are isolated, and, subsequently, either in sync or operating in confusion and chaos.

    This is still common, but avoidable. The means of communication are more abundant than ever. We can text, email, use collaboration apps or even the obscure method of speaking into a telephone to another human in real time. Yet, despite all these methods, DevOps teams still find themselves taking too long to become aware of issues that need immediate attention or action. Or, we realize too late that multiple people are responding to or chasing down the same issue. Ironically, the easier it is to communicate and even automate communication across all of the different methods, the more likely we get inundated and saturated by what we really need to be paying attention to.

    What’s the best way to cut through all the noise? DevOps teams can:

    1. Filter the junk and cut down on the noise to begin with—without missing something important.
    2. Direct the relevant info only to those people that need to take action, and only when it’s the appropriate time.
    3. Require an acknowledgment that the recipient is taking ownership of the issue.
    4. Or, of course, all of the above.

    There have been tools available over the years to tackle these noise-slaying objectives. Some do a great job getting info to our team’s pertinent DevOps information, but with no way to filter out the irrelevant or redundant stuff. And others can do some of everything, but are complex to set up and maintain and expensive to use.

    DevOps teams I’ve talked to want to be able to:

    • Immediately and automatically send critical, actionable alerts.
    • Route alerts to the right people immediately, but only when it is the appropriate time to do so (don’t wake up the wrong teammate!).
    • Speed alert response with automated acknowledgment and escalation.
    • Automatically communicate through text, email, voice mail and mobile app, all custom-designed for DevOps use cases.

    The prevalent expectation goes beyond easy-to-use, simple to start and maintain solutions. Effective tools also must meet the increasing demand for agile and efficient collaboration among DevOps team members who often use multiple communication tools.

    • Filter out the noise, but don’t miss the important stuff:
      • Filter alerts, (e.g. by problem severity), so you can focus on real problems and disregard IT operations noise. Create custom groups of contacts to make sure the right notifications reach the right team member, and streamline the process of determining who to contact when specific problems occur and how to contact them.
    • Notification channels:
      • Define experts who can respond to problems and store their contact details so they can be notified automatically of problems in their area of responsibility. Users should be organized into groups and so you can send notifications to several users at once. Notifications should able to be sent by email, SMS, mobile app, voice message and chat apps.
    • Alert management and notifications:
      • Tools with policy-based notifications can let you define which type of subject matter you want each person or group to be notified about. You should be able to create filters based on the alerts that occur, customize the filters and assign users and groups who are notified when matching problems occur. Unacknowledged alerts should be escalated automatically after a set time period to the appropriate contact. Filters such as the severity and status of alerts can be created for your IT monitoring requirements.
    • Scheduling:
      • You’ll want to be able to easily set up on-duty and on-call shifts. The process of scheduling is considered to be one the most time-consuming tasks that prevent users from utilizing a notification tool. A good scheduling capability should be intuitive and require minimal steps to use. Users should have the ability to customize or use out-of-the-box templates. Users also should be able to manually create shifts or build in shift patterns, such as follow the sun, to get their scheduling done faster. Scheduling capabilities also should be smart enough to schedule users or groups for weeks in advance.
    • Alert viewer:
      • You’ll also need to be able to monitor alert and notification status in management views, perform actions on alerts, and track them in real time. Seeing key alert information such as alert severity can help you enable to easily prioritize your to-do list. You should be able to track alerts from their receipt by the system through acknowledgment to resolution and changes in an alert history, and use predefined and real-time filters to designate alerts you want to see.

    Utilizing the capabilities such as these can empower you to improve responsiveness, save resolution time and focus on actionable notifications requiring immediate attention.

    About the Author / James Moore

    james-mooreJames Moore is responsible for offering management and strategy for IBM IT Service Management hybrid cloud-based solutions including Runbook Automation and Alert Notification. James joined IBM from the Candle acquisition in 2004, where he was product manager for Candle’s Application Response Time product lines.  James has more than 15 years’ experience in business service management, application performance management and event management. Connect with James on LinkedIn and Twitter.

  • Top 5 Traits of High-Performing Teams

    Top 5 Traits of High-Performing Teams

    DevOps is here and it seems to be what everyone in IT service management (ITSM) is buzzing about. So what are the goals and how do we know it’s not just the next hot kitchen color for this year? DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while leveraging agile, lean and traditional ITSM practices.

    Stakeholders on the development side will include, but not be limited to, all of the people involved in developing software products and services. On the operations side it will include, but not be limited to, all of the people involved in delivering and managing those software products and services and the underlying IT infrastructure on which it is being delivered.

    The goals are to better align IT responsiveness to business needs, smaller more frequent releases, reduce risk, increase flow, improve quality and reduce time to market. These can only be accomplished by understanding the entire value stream, including the lead times and cycle times of the different areas that make up your value stream.

    Let’s take a look at the top five predictors of IT performance and see how engaging DevOps practices enhances our ability to become high-performing teams.

    1. The peer review change approval process provides enhanced and effective communication. When technical teams hold themselves accountable for the quality of their code through peer review their performance increases, resulting in 200 more times frequent code deployments, according to Puppet Labs’ “2016 State of DevOps Report.” Allows for an on demand deployment (multiple, daily releases) structure.
    2. Version control for all production artifacts. This provides a single source of truth for all changes. An integrated and automated tool chain along with practices such as continuous integration result in a three times lower failure rate, according to the report.
    3. Proactive monitoring enables teams to diagnose and solve problems faster and have a higher degree of accountability. Tie that in with a single source of truth and that results in 24 times faster mean time to recovery (MTTR), the report noted.
    4. High-trust organizational cultures allow for experimentation and learning, allowing people to take intelligent risks. Having this culture promotes the idea that repetition and practice is the prerequisite to mastery.  According to the Puppet Labs report, organizations with high NPS (Net Promoter Score) have shown much higher levels of employee retention and are 2.2 times more likely to recommend their company as a good place to work.
    5. A win-win relationship between Dev and Ops. It’s not Dev versus Ops, it’s Dev and Ops. Shifting left is about building quality into the software development process. When you shift left, fewer things break in production because issues are detected and resolved earlier. By building quality into the software development cycle, high-performing teams spend less time on unplanned work. We also found they spend less time remediating issues and spend more time on new, value-add work.

     

    — Drew Lapatin

  • The 3 Secrets to Overcoming the Agility-Stability Paradox

    The 3 Secrets to Overcoming the Agility-Stability Paradox

    Regardless of whether an organization subscribes to a bimodal IT approach, one thing is clear: It’s more important, and more difficult, than ever to fight the agility-stability paradox. Today’s businesses must build on a delicate balance of being compliant, plan-driven and keeping the lights on while also seeking ways to become more fluid and agile with high customer touch. The barriers standing between these two key initiatives are numerous and complex; whether it’s mismatched technology or a lack of mutual understanding, the agility-stability paradox remains.

    In a lot of ways, this paradox comes down to a difference between traditional and new forms of IT. Traditional IT can be described as predictable–it’s compliant and plan-driven, with conventional processes and long-term cycles. But as the next generation of IT starts to take hold, today’s businesses must find ways to also fold in a new IT that’s dynamic, fluid, agile and continuous, with short cycles and high customer touchpoints. In this way, traditional IT and new IT are polar opposites, and many companies struggle to find a balance between the two. Competing attitudes, too much change at once and tooling challenges all stand in the way of harmony between the reliability of the traditional approach and the need for agility in the new way of doing things.

    Balance is Possible

    While there is no magic tool or wand that can solve for the incongruities so many organizations face, balance is possible. Enterprises don’t have to choose reliability, customer experience, uptime and performance over agility, release velocity, new markets and competitive response. The real secret to overcoming the agility/stability paradox lies in establishing who, what and how. What this means is that with the right people, processes and tools in place, any company can achieve the balance between agility and stability needed for success.

    Who? People

    People serve as the “who” of finding balance between reliability and agility. This is the chance to integrate your culture into solving the agility/stability paradox. Start by identifying how each member of the team needs to adapt and shift to accommodate changes. The real trick to getting the people aspect of things right is communication. Define a communication path and be really clear about why your organization needs to transform, how it will be transformed and when everyone can start expecting to see some real adjustments take shape. Orchestrate a response mechanism across your teams and enable social operations collaboration to facilitate execution. Be sure to provide ongoing updates and encourage feedback.

    What? Process

    Now that you’ve established who needs to play a role in overcoming the agility/stability paradox, it’s time to talk about what exactly needs to change. Process is absolutely crucial here. There are a few keys to establishing the right process for balancing traditional and new IT models. The first is to identify, and not dictate. Dictating change from the top down is never going to be effective. Instead, work together to determine areas of weakness and highlight them. Use your observations as a guide, not a mandate.

    From a more tactical perspective, be sure to streamline workflows wherever you can. Define instead of inheriting urgencies and alerts. Don’t be afraid to rely on automation wherever possible, either. By automating processes that help out on the people side of things, you can free up your team to spend less time on tedious, manual tasks and focus more on innovation.

    How? Tools

    Tools are your best friend when it comes down to actually making all this change happen. Considering the vast number of tools in the market, choosing a toolset may appear daunting at first. But if you start with strong integration across the operational modes already in place, then you’re already in good shape. In particular, to bring new, agile IT into the fold, you’ll want to incorporate IT service management (ITSM) solutions and establish a DevOps tool chain.

    Don’t Boil the Ocean

    The most important thing to remember is to start small—you don’t have to boil the ocean. Build a culture where traditional and new IT environments are encouraged to work closely together, where you can build and run software that addresses both agility and reliability to respond to the pressures on the business. Start by defining what is is right for your team and organization and acknowledge the existing culture and people. Don’t be afraid to experiment and create isolated learning environments, either. Just make sure to maintain a clear connection to customer value and use this as your North Star. Finally, don’t forget to celebrate. Celebrate your failures and learn quickly from them.

    About the Author / Manish Kalra

    manishManish Kalra is director of Product Marketing at PagerDuty. He is responsible for driving product marketing strategy, product positioning, launches and collateral development for the PagerDuty incident management platform. Prior to PagerDuty, he served as Director of Product Marketing at companies like Sumo Logic and Splunk.

  • DevOps Chat: CJ Paul, IBM, on DevOps, ITSM, Cloud and More

    DevOps Chat: CJ Paul, IBM, on DevOps, ITSM, Cloud and More

    devopsy.kinsta.cloud editor-in-chief Alan Shimel sat down to speak with Dr. CJ Paul, Distinguished Engineer, DevOps Methods & Tools, IBM Cloud. CJ is someone we have interviewed previously on video at IBM InterConnect and is always a great source of information. In this interview Dr. Paul discussed DevOps, ITSM, Cloud, Bluemix, Bluemix Garage method and more. 

    As usual, the streaming audio of our discussion is below. You can also find it on SoundCloud and iTunes. Below the audio player is the transcript of our conversation so you can follow along. Enjoy!

    Shimel:  Hi, everyone. Alan Shimel here for another DevOps Chat on devopsy.kinsta.cloud. Thanks for joining us. I’m happy to be joined on this episode of DevOps Chat by a friend of mine CJ Paul of IBM. CJ, are you there?

    Paul: Yes. Hi, Alan. How are you?

    Shimel:  Good. Good to have you on DevOps Chat with me today, CJ. Of course you and I have done several video interviews from various conferences we’ve both attended. But you know we haven’t had the pleasure of having you here, so welcome. CJ, I’m gonna bet not everyone in our audience knows who you are. Why don’t you give a quick little background on who you are, what you do, where you work and so forth?

    Paul: Yeah. Definitely. So my name is CJ Paul. I work at IBM. I’m a Distinguished Engineer in the cloud unit. And focused on DevOps methods and tools. So some of the things that my team puts out are the Bluemix Garage Method. It’s out as a website at IBM.com/devops/method. Then we also work on the Bluemix DevOps services and you know I work with a lot of clients as they do their transformation to the cloud. And trying to develop DevOps practices along the way.

    Shimel:  Great. So CJ, you know just kind of off the beaten path here, but we’ve had several guests on DevOps Chats that are distinguished engineers at IBM. And for our listeners who you know maybe are not familiar with what that means and it’s more than just a pretty title. Can you give our listeners a little bit of insight into what it is to be a distinguished engineer at IBM?

    Paul: Oh, definitely the focus of a distinguished engineer is to leave a portfolio of products in a particular domain. So in this particular case you know I have several product teams that work on different offerings in the DevOps space. And I’m responsible for crafting the technical strategy and providing architecture and technical direction to multiples of these teams.

    Shimel: Got it. So CJ, as I think I mentioned to you in our off camera or off microphone conversations, you know the month of September is gonna see devopsy.kinsta.cloud focusing a bit on APM and DevOps. And of course this is a subject that you are you know very familiar with. And part of what you do in Bluemix and all of these things, obviously APM’s a part of it. But why don’t we start with this? Can you define for our audience, when we talk about APM and DevOps and maybe it’s in relation to ITSM, right? IT Service Management which is something you’re also very familiar with. Can you kinda pull this all together for us?

    Paul: Yeah. Definitely. Traditionally operations teams have always worried about application availability and performance. Where performance includes you know how the application might respond from different locations around the world and how the response time evolves or changes for different types of transactions. Now, as we look at DevOps and the role of the DevOps teams becoming more cross functional, a lot of the focus is shifting to how do we get the synthetic monitoring, the configuration of the monitoring and all of that to be handled much earlier in the development cycle. In fact, in an ideal world, just like our source code is written to the specs of the product, we would also create the associated operational configuration of the monitoring tool, as well as the creation of the synthetics scripts, along with the source code. And so in the ideal case you would have all that be checked into the same repo. And then as part of your continuous delivery process you’d want to make sure the operations tool is configured to monitor that particular build that is deployed in a particular environment.

    So that’s the shift in thinking that we see a lot of the teams going through is how do we actually make this possible you know where all of the setup and configuration is treated as an extension to the source code of the product and worked through the lifecycle. Because it gives various advantages. Let’s say a new build comes out and you’re going to go deploy that new build in a particular environment or perhaps even introduce it to a small subset of your users in production. When you introduce that new build with a new feature, you want to monitor that new build or that new feature. And take all of that data and make decisions on whether you now ramp up to your full population. So what we see happening is in the new world of DevOps and especially on the cloud, you know monitoring has to go very much hand in hand with the features that the development team has built. And so it’s no longer just an after the fact operations thing to worry about. It is something you have to worry about as an integral part of the DevOps lifecycle. So that’s why I think this is a really exciting time. Especially the cloud enables application teams to do A/B testing and evaluate you know performance of new features, the response times of new features as it compares to their existing version of the application that is running.

    Shimel:  Sure.

    Paul:  And so all of the new capabilities you know that are the focus area in the application performance management space.

    Shimel:  Sure. Exciting times indeed. CJ, I would be remiss if I didn’t mention on this very topic that we actually have a webinar scheduled, I believe it’s Tuesday, September 20th at 1 p.m. Eastern Time with a colleague of yours at IBM, Arun Bilgiri.

    Paul: Yes.

    Shimel:  Are you familiar? Yeah.

    Paul: Arun Biligiri.

    Shimel:  Yes.

    Paul: Yeah.

    Shimel:  And Arun is gonna be doing this on Learn Why We Must Shift APM Left in the DevOps Lifecycle. And he’s gonna be also joined by Dan Kern, Solution Architect over at Prolifics. So you know if you’re listening to this and this is a topic of interest to you, not you CJ, I know you’re interested. But our audience, I’d highly recommend. You can probably register for this off of our devopsy.kinsta.cloud. Go to the Webinar and Events page and you can register there. But it should be dead on on topic for this. So CJ, I wanted to focus back on though this idea of shifting APM left, right. So when we talk about DevOps and how we fit in things like security and QA, now APM, that seems to be a common theme of shifting these things left. Get them earlier into the development process, right. Because the earlier it’s in, hopefully the better it comes out in the end, right. I guess my question to you CJ, is can we just continue shifting everything left, right. You know what I mean? Is there a point of diminishing returns of shifting left?

    Paul: Yeah. I think in this particular case especially, you know it’s something that is a good thing to think about right from up front. Especially as the velocity of deployments increases, we would expect the development teams to be more and more you know working the monitoring of the applications in conjunction with the code. Because you’re just kind of thought to have a throw it over the wall kind of syndrome. Because you know that would be too slow in this world to make it successful. So that’s why I think the shift left is almost an inevitable side effect of the need to go faster. And also with some of the shift to cloud, you know the way things are done are also different. So more and more the application architectures and topologies are becoming more complex to handle geographically distributed deployments and so on.

    So more and more we expect the development teams that are involved to be doing some of these operations automation just like they would work on you know features for the product. So some of these concepts surround you know cycle liability engineering and so on that are being out in the industry are just examples of why you know we’ll get more and more of a DevOps perspective on things that used to be just purely operations activities in the past.

    Shimel:  Got it. CJ, my next question with you on this is and by the way we’re running low on time so I only have one or two more questions left. Is you mentioned earlier one of my favorite things happening in IBM and that’s the Bluemix Garage method, which is an open source methodology kind of taking best practices and lessons learned from IBM themselves, as well as your partners into this methodology. Talk to us a little bit. Where does APM fit into there?

    Paul: Yeah. So with this Garage method what we’ve been doing is to take the learnings from across the industry on agile practices and design thinking and you know the latest DevOps practices and lean practices and so on. And organize it in such a way that enterprises can learn how to act like a startup but do it at enterprise scale. So within that method, we talk about how you think and plan, and code, and deliver, and run, and manage, and learn around a whole culture of DevOps. So in this particular case as we talk about application performance management, we typically think of it in managed. But as we have been discussing here, it kind of permeates through the lifecycle because you have to think about the availability of your applications as you design and build them. And you have to write the code for the synthetic monitoring steps, along with your features of the product. And you have to deploy them as part of delivery. And then clearly you’ll collect and analyze the data as part of manage and learn. So I think this whole shift left of APM fits in very nicely with the Garage method and its different lifecycle phases.

    Shimel:  Got it. CJ, I apologize, but just as I promised, yeah, we’re way over 12 minutes already and we’re gonna need to wrap things up here. But before we do, I wanted to just ask you one final question which is usually one that I ask most of our guests here on DevOps chats. CJ, for our listeners out here, if you had to recommend one book that they should read, what should be the next book they read?

    Paul: I would highly recommend folks read the Site Reliability Engineering book that has come out of Google. They talk about how engineers with development skills can automate a lot of what used to be production activities. That’s a very good read. Within IBM we’ve been doing these kinds of activities ourselves. You know me make sure that the individual squads are also responsible for their performance. But I find this is a good book for teams to look at if they haven’t already read it.

    Shimel:  Got it. Okay. CJ Paul, Distinguished Engineer at IBM. Thank you for being this episodes guest on DevOps Chats. Look forward to seeing you in person at some conference or another soon, CJ. And until then, keep up the great work.

    Paul: Thank you, Alan.

    Shimel:  This is Alan Shimel of devopsy.kinsta.cloud for DevOps Chats. Thanks everyone. Have a great day.

  • DevOps: Achieving Process Without Too Much ‘Process’

    DevOps: Achieving Process Without Too Much ‘Process’

    While there’s no fundamental conflict between IT service management (ITSM) and DevOps, DevOps does bring new and different techniques for getting work done and interacting with the rest of the organization.

    ITSM people who are used to frameworks such as ITIL and COBIT tend to regard the IT department as a “service provider” and the rest of the organization as “the customer.” But DevOps has come from web-scale organizations “where IT is the business,” and that means the prevailing view is more like the Toyota Production System mentality, wherein the aim is to move things along a production line with maximum speed and maximum quality, says Matt Hooper, product evangelist at LANDESK.

    DevOps thus has already broken down some of the barriers between “IT” and “business”—practitioners realize they have to determine what the business needs, and then provide it. But Agile or Agile-like practices also are part of this approach, so there’s lots of experimentation, learning and redeployment in “lots of tiny little steps,” and, consequently, there’s not much risk of going very far wrong with any of them.

    An issue is that this conflicts with ITSM’s view of life cycles, partly because the whole idea is to merge development and operations—for instance, by automatically spinning up software-defined infrastructure as needed.

    What’s needed, Hooper suggests, is “service management with a digital mindset” rather than ITIL’s “human mindset.” It’s all about feedback, he says, but for ITSM and DevOps to sit comfortably together there must be a realization that feedback can come from humans or systems.

    And even though the command and control mindset tried to avoid failures, systems still failed. So a better approach is to accept that “stuff breaks” and make small changes at a time, respond to issues as they arise and keep learning. In the longer term, this will lead to more durable systems, he says.

    It’s a myth that you’ll be able to stop bad things happening, because people and systems aren’t perfect. DevOps, in contrast, accepts that things will go wrong but aims to respond quickly—for example, by keeping developers close to operations so they can see problems occurring, realize what mistakes they made, and put them right.

    “That’s challenging to a traditional ITSM person,” Hooper says. It is important to accept that failure is an option, even though massive failure isn’t.

    (Before you ask, he accepts that certain systems need to be extremely reliable. But others provide room for a somewhat experimental approach, in which case DevOps helps avoid overengineering.)

    While some ITIL practitioners see value in DevOps’ continuous deployment approach, their premise is still that IT is a “service provider” rather than a “partner,” but the business side of the organization wants the latter. You don’t get home from a business trip and tell your spouse you were 99.98 percent faithful while you were away, he observes, and that sort of SLA-based thinking works against becoming a learning organization, achieving good demand management and so on.

    ITIL v2 served a good purpose, but ITIL v3 arrived too late, Hooper suggests. The growing influence of the Lean movement means systems are going through rapid change cycles, and too much “process” leads to waste and lower performance. DevOps and software-defined technologies provide ways to better handle rapid change—infrastructure can be spun up and back down in seconds, providing opportunities for self-healing systems with better scalability and reliability.

    Where ITIL focuses on meetings and human processes, DevOps prefers to use analytics to determine the right time to release and then whether then release was successful. “The feedback loop is an essential part of DevOps strategy,” just as it is with ITIL, but ITIL has a more human-centric idea of feedback.

    “ITSMers tend to hide in the back closet” waiting for the business to tell them what to do, but DevOps takes a more active approach, he suggests.

  • Let’s Talk About Ops: An ITSM Crowd Special

    Let’s Talk About Ops: An ITSM Crowd Special

    The ITSM Crowd is a regular hangout hosted by DevOps training provider ITSM Zone that covers many different IT and management topics. On Aug. 11, host Claire Agutter was joined by IT Skeptic Rob England and James Gander from Gander Service Management to take a deeper dive into the impact that DevOps is having on operational roles.

    Gander comes from an operational background and wanted to discuss how the role of ops is changing, and England works with many clients who are evolving to work in more agile ways, embracing DevOps principles.

    DevOps Needs Ops

    All agreed that DevOps doesn’t mean No-Ops.  The traditional “build” and “run” phases are no longer clearly demarcated. Dev will work with Ops to improve and fix live services, and Ops will provide Dev with feedback that will help them to improve.

    Ops also needs to embrace the role of “toolsmith” or “toolmaker.” It can support Dev by creating environments that make it easy for Dev to do its job. This could include providing fast, automated access to virtual servers or providing input on monitoring and event management.

    Elements of Ops such as the service desk are essential and will never disappear. Customers always will need to be able to contact IT, so this part of the operational role will be present in some form, perhaps moving toward a greater focus on self-service.

    Ops Processes Won’t Disappear

    Traditional operations processes also still have a place. Change management, for example, is still essential, but it needs to “get out of the way” and enable change to happen, rather than acting as a barrier.

    Ops staff need to treat DevOps as an opportunity to learn and improve, not as something to be resisted. There are many great blogs to get started with, and this is an exciting time to be working in IT.

    You can view the video here, and I’d love to get your feedback and comments on how you think DevOps is changing the role of operations.

     

  • REP SPOTLIGHT: getITright

    REP SPOTLIGHT: getITright

    DevOps Institute: Tell us a little about your organization.

    getITright: With offices in Australia, South Africa, The Netherlands, Nigeria and Malta and a network of partners operating in 31 countries, we offer a bouquet of services to help organizations to:

    • Manage better
    • Lower risk
    • Perform better
    • Make better business and IT decisions

    Our service offering includes:

    • Training courses – Learning best-practice through our Partner Academy courses or network of training providers
    • Accredited IT Best practice course material – License our training material
    • Consulting – We use an agile approach for projects and a lean approach for operations when consulting and coaching.

    DevOps Institute: What other topics do you teach or consult on?

    getITright:

    • Service Management: ITIL®, ISO/IEC20000, Lean IT, Service Desk Institute
    • Governance of Enterprise IT: COBIT® 5
    • Project Management: PRINCE2®, PRINCE2® Agile, DSDM AgilePM®, Scrum
    • Information & Cyber Security Management: ISO/IEC27001, NIST Cybersecurity using COBIT5
    • Quality Management & Business Improvement: ISO9001, LEAN SIX-SIGMA
    • Risk & Continuity Management: ISO31000, ISO/IEC27005, ISO22301
    • Cloud Computing

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    getITright: DevOps awareness in the region is still low, but we see a steady increase in the level of interest in the topic.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    getITright: It makes projects and business as usual faster, more stable, with less risk.

    DevOps Institute: What topic area in DevOps excites you the most?

    getITright: DevOps enables organizations to improve productivity and respond to change with less risk. It’s easy to adopt by organizations with mature ITSM practices in place.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    getITright: Training ensures that all resources in the organization are in sync when implementing new practices like DevOps in an organization and ensures a cohesive approach that facilitates proper organizational buy-in and adoption.