Why do you have to burn the IT ticketing system
ticket system is one of the most common obstacles that hold back the operating team from being a high-performance, which is essential for the digital transformation of IT.
Most people who have held the job operation-types who are familiar with the ticketing system: They record demand for Ops team of IT so that everyone involved in the process have visibility into when the item requested, who requested it, carry out the task, how long it took to complete, etc
This all sounds like a good thing to track, and they tell you all sorts of things about the work that was going on. But when I saw this pattern in an organization, here's my advice:
burn
I'm not talking about the walls Scrum or Kanban board here. In other types of work-tracking system, the team is empowered to decide which jobs are most important, and then help you prioritize the right job for best results. I mean the system are the ones where a person makes a request for the host Jenkins, AWS EC2 instance new, or hosts to be added to the load balancer. The type of work that is required to operate the service production, but which falls into the domain of IT operations (or DevOps engineers, site reliability engineers, production engineers, etc.) to meet.
There are several problems with this approach that I will dive into my talks in Las Vegas DevOps Summit Virtual Company. First, the ticketing system requires a wait, and wait like this should be classified as waste, such as in lean. Second, the ticket system software should be seen as an exception thrown by value stream. However, the third issue I want to address here: hard work. If your organization is designed such that the value stream flows through humans operate on a ticket, then your ticketing system designed to keep track of hard work.
What is hard work?
In Chapter 5 The Google SRE Book, Eliminate toil, Vivek Rau writes: "Toil is the type of work associated with running production services tend to be manual, repetitive, automatable, tactical, without enduring value, and that a linear scale as the service grows." There's a lot there to unload, but here are the key concepts of Rau which shows how a ticketing system designed to keep track of hard work.
Manual, repetitive, automatable
If this work is sit and wait until the man came and took it from the queue before it can be executed, then it is by definition a guide. Even if some automation to execute after the job is taken, people still carry out the work. The fact that this work needs to be done as a result of the ticket must also be shown repeatedly his creatures. Do something totally automatable is a matter of debate, but if it is something that happens over and over again, is not it worth examining more closely as a candidate for automation?
A linear scale as the service grows
At this point, I do not agree with Rau. I believe that hard work sub linearly scales as the service grows. Why? Because the cost of coordination involved in implementing many of these tasks: More and more of the kind of job you are trying to push through the system, the worse the system will perform. There are only so many minutes in a day that you can wait for someone else's job to finish first, or approval must be granted by the change advisory board to make changes in the environment, or between changes so that if there is generated an outage, you more clearly where change is the one who caused the problem.
This is a problem as the organization grows. The more successful the organization is, the more likely there will be a lot of hard work that the system needs to process. If you start with the responsive, well-liked and you want to maintain the same level of service for your organization, then you will need to hire more people to execute on hard work-which means it will hire you scale linearly with your hard work and still slowing. To what end? The best one can hope for in this case is continued to tread water and stuck right where you are. No wonder that the big companies can have problems such as executing compared to smaller, more nimble competitors them.
Transformation
Obviously, the road continues to process much toil is not sustainable. But what is the alternative? How do you begin to eliminate the hard work? Like all transformation initiatives, changes must be intentional. When working with the company on this issue, I followed the Dominican Degrandis' advice and make the work visible. You need to check the type of work being done and to characterize it. How would you characterize the work may be different for different organizations? Maybe you characterize by time, value, or with cardinality. Regardless of your scheme, you are looking for a job that can be eliminated, either because it is not needed or because the work that you can empower teams to do for themselves.
If an autoscaling group of three nodes need to be increased to four, maybe you can ask your team pull request to be reviewed and implemented by IT operations. Even better, if the pull request is considered safe by the script and have a code-reviewed by other members of the team before the request is submitted, it may be applied automatically. Even better, there may be a way to reexamine the algorithm by which you measure your autoscaling group so that the group will autoscale itself appropriately based on several criteria.
You do not, however, want to create or perpetuate a system where people have to check the code ops infrastructure, create new branches, making changes to the 1-byte, and so on, all in the context of the ticketing system. In many cases it may be, you want IT Ops teams to empower organizations to provide self-service platform where teams can make changes themselves in a safe manner. This is the cloud service providers to offer to their customers.
Now I overstaffing
If you've hired more engineers to keep up with all the hard work, does that mean you will have a big round of layoffs? Certainly not. I have worked with the company to take their staff members who have been working on their ticketing hard work and a special focus on the empowerment component of the problem. Their task will be to completely eliminate the hard work as much as possible.
You can also take some engineers are more junior and place them in your development team to create a team that is truly cross-functional which has the ability to move as fast as the organization will let them, because they will have all the necessary skills and won 't have to wait , They engineers can also provide valuable feedback for your "hard work eliminator" because they understand the problems they are facing a team in a deep level, and operational concerns, and is able to speak the language back to the team eliminator. This is a great way to generate high-fidelity feedback while giving your engineers valuable experience working with the development team to understand their needs.
Comments