12 antipatterns DevOps
From the translator. Continuing a series of translations about DevOps, this time I want to talk about how to do NOT. We encountered this every time something new comes up, such as agile. There are cargo cults, voices are heard that we are special and everything is wrong with us and so on. So let's try to avoid this in the case of DevOps.
So you want to become DevOps? Good, but before you begin, let's take a look at some things you should not do.
In the good old days, we simply called them “bad ideas”, but diplomacy and political correctness appeared, brainstorming went away and the idea shower appeared, and with it the word “anti-patterns”.
')
If the “pattern” is the right way, then the “anti-pattern” is inherently wrong - and therefore, to prevent you from going the wrong way, we have compiled this list (with a little help from the DevOps community).
Not really. This is a philosophy. This is a way of thinking. DevOps is supported by processes and tools. DevOps, according to Gene Kim , is based on 3 basic principles known as the “Three Ways”
The first path emphasizes the performance of the entire system - the value stream.
The second way says about the reduction and acceleration of the feedback cycle.
The third way is to create a culture that promotes continuous learning and mutual understanding.
( Read more about this in the translation of the article "11 things you need to know about DevOps", part 2 and 1 )
If you ask this question, then you are probably working on some agile process. Not bad. You have a software development process that follows DevOps values, but Agile does not mean that you have implemented DevOps.
DevOps transfers agile values ​​to the administration department, allowing you to streamline the flow of tasks to incoming administrators and allowing this flow to go further to the client, turning tasks into value for the end user.
CIO: "I want to go to DevOps over the next year."
MGR: “Already done, we changed the signs on the doors of the departments this morning. We are so cool that now we have 2 DevOps teams. ”
Well, super easy. And I'm sure you now have a lot of DevOps engineers. If you are lucky, they can sit next to you at lunch.
Go on. I beg you very much. Already? Well done! You implemented DevOps. In fact, what you just did was create another silo tower. Now you got yourself another team that you need to try to integrate into the current process. Another team surrounded by walls to break. Maybe it is worth going back, re-branding and creating 3 DevOps teams and becoming super cool?
DevOps does not say that you need to pull a few people out of development and administration and pack them into a new team. You must accept and implement. Join the development team in the administration team or vice versa. You need to completely destroy the barriers / walls / guards between the teams and form them into one with the common goals and responsibilities.
More details on the link
DevOps. This is a word that begins with "Dev." This means that development becomes more important, because development comes first ... problems?
DevMgr - “Uh, we're doing DevOps now. My guys have to learn how to work on production. ”
OpsMgr - “Uh ... well. So who will develop the code? „
The word DevOps is clever. It is a derivative. This means that it is a combination of two words in order to form a new word that gives a new meaning. It even has some efficiency. This does not mean that we took the word operations and replaced it with the word development. So why don't you try and take DevOps in exactly this way?
DevOps requires both groups to use their key skills. And shared what should be common to work together. Learn what needs to be learned for improvement. This does not mean retraining. This does not mean cross-functionality (however, this can be a positive side effect). This means providing feedback and transparency to improve.
If you think DevOps is just a buzzword, then you probably use the “clouds” incorrectly. DevOps is like a medal to get.
DevOps is more than just a cool word. It's a state of mind. You must accept his values, you must help others accept his values ​​and you must constantly improve yourself and help others improve in order to be successful. As soon as you drop all your ambition and start working together, you can make people think that “DevOps” may actually sound cool.
DevOps is like voodoo. In general, get your team of developers and administrators working together. They smoke something and then sacrifice a chicken. Once you have done this, your organization will never be the same. You will be able to deliver software faster than ever before. The configuration will be self-managing. Your deployment tools will become intelligent. Your development and administration teams recognize harmony.
Get it ... DevOps is hard work! For most, this requires a culture change! This is one of the hardest things you've ever tried. For experienced developers and administrators with whom you are trying to create it, it will be the same as getting upside down. Do not try to do it overnight, otherwise fail.
Not! Heck no, and no again. He himself is shaking with anger that you have to read this ...
Let me clarify 2 things.
DevOps is not managed by development.
DevOps is not managed by administration.
If you want an environment developed by development, well, go and create one. Just do not call it DevOps. Therefore, it is not.
Take a look at this article as an example .
“In DevOps, programmers are programmers.” - Exactly!
"In the same way, in DevOps, admins are admins." - We are ready!
“Traditionally, the tasks of issuing software to a combat server are the responsibility of administrators or development teams.”
Wait a minute ...
“Administrators create deployment strategies to minimize downtime and ensure stability through flexibility and responsiveness.”
Yes, we returned to the familiar rails ... and now bang!
Release Management through Development - WTF? The situation gets worse
“Release management through development follows a different path and looks at how deployment can be carried out as often and easily as possible. However, these deployments do not necessarily occur in production ... From a process point of view, continuous delivery has two big requirements: first, the process itself must be sustainable outside of development. This means that it must be sustainable, like any process which the traditional administration team can implement. "
Not. No. Non. Nej. Na. Nee. Nein.
Development-driven can be a process. This is just not DevOps. Replacing administrators with an automated deployment process is nonsense. Please do not try this at home!
Yes you are, yes you are my clever! But you are not so special that you cannot become DevOps. I bet you are the best developer there, the speed of your code is faster than the speed of light, and when other programmers see it, they cry for joy. Not? So, you are the most amazing Ops on the planet. If Chuck Norris were the administrator, he would be you. However, you and your organization do not have any such factor that will not allow you to implement DevOps. So let it happen to you!
Opscode's Jesse Robbins has some good tips for getting started:
And useful for reading.
Why do you hire them? That is why - they are awesome! If you do not think so, then you need to take a close look inside yourself, and then go and discover the real hidden talents in your team.
Someone told me recently that they could not do DevOps, because "they have the wrong developers and administrators ...". Is it that they have developers who can't write code? I thought to myself: “Bad developers work in my company - people who cannot program, they work HR and marketing!”
DevOps promotes collaboration between development and administration. This collaboration should be developed at the policy level of the entire company.
And do not say that you work "wrong" people. You just do not know how to cook them. Fight it.
Okay, genius. You are about *** ***. So what? We all do it. But now you want your admin guys to get out of bed at 2 am to do a sweep of what they know nothing about. They are admins, not “cleaners,” like Michael Clayton. Wait until the error occurs during deployment to begin the interaction between developers and admins is a complete mess.
It's too late for this problem ... but maybe not for the next one. You have a team of developers and admins who communicate (or swear at 2 am) with each other, but at least they speak. Keep the dialogue constant. Get a retrospective review of what happened and how you can fix it in the future. If you are faced with this situation, then try to keep the dialogue between the teams. Open channels of communication between developers and administrators as early as possible. And then hope is not lost!
So you want to become DevOps? Good, but before you begin, let's take a look at some things you should not do.
In the good old days, we simply called them “bad ideas”, but diplomacy and political correctness appeared, brainstorming went away and the idea shower appeared, and with it the word “anti-patterns”.
')
If the “pattern” is the right way, then the “anti-pattern” is inherently wrong - and therefore, to prevent you from going the wrong way, we have compiled this list (with a little help from the DevOps community).
1. DevOps is a process
Not really. This is a philosophy. This is a way of thinking. DevOps is supported by processes and tools. DevOps, according to Gene Kim , is based on 3 basic principles known as the “Three Ways”
The first path emphasizes the performance of the entire system - the value stream.
The second way says about the reduction and acceleration of the feedback cycle.
The third way is to create a culture that promotes continuous learning and mutual understanding.
( Read more about this in the translation of the article "11 things you need to know about DevOps", part 2 and 1 )
2. Agile is the same as DevOps?
If you ask this question, then you are probably working on some agile process. Not bad. You have a software development process that follows DevOps values, but Agile does not mean that you have implemented DevOps.
DevOps transfers agile values ​​to the administration department, allowing you to streamline the flow of tasks to incoming administrators and allowing this flow to go further to the client, turning tasks into value for the end user.
3. Rename your team of admins / developers / anyone in DevOps
CIO: "I want to go to DevOps over the next year."
MGR: “Already done, we changed the signs on the doors of the departments this morning. We are so cool that now we have 2 DevOps teams. ”
Well, super easy. And I'm sure you now have a lot of DevOps engineers. If you are lucky, they can sit next to you at lunch.
4. Run a separate DevOps command.
Go on. I beg you very much. Already? Well done! You implemented DevOps. In fact, what you just did was create another silo tower. Now you got yourself another team that you need to try to integrate into the current process. Another team surrounded by walls to break. Maybe it is worth going back, re-branding and creating 3 DevOps teams and becoming super cool?
DevOps does not say that you need to pull a few people out of development and administration and pack them into a new team. You must accept and implement. Join the development team in the administration team or vice versa. You need to completely destroy the barriers / walls / guards between the teams and form them into one with the common goals and responsibilities.
More details on the link
4. Hostile takeover
DevOps. This is a word that begins with "Dev." This means that development becomes more important, because development comes first ... problems?
DevMgr - “Uh, we're doing DevOps now. My guys have to learn how to work on production. ”
OpsMgr - “Uh ... well. So who will develop the code? „
The word DevOps is clever. It is a derivative. This means that it is a combination of two words in order to form a new word that gives a new meaning. It even has some efficiency. This does not mean that we took the word operations and replaced it with the word development. So why don't you try and take DevOps in exactly this way?
DevOps requires both groups to use their key skills. And shared what should be common to work together. Learn what needs to be learned for improvement. This does not mean retraining. This does not mean cross-functionality (however, this can be a positive side effect). This means providing feedback and transparency to improve.
6. DevOps is another buzzword
If you think DevOps is just a buzzword, then you probably use the “clouds” incorrectly. DevOps is like a medal to get.
DevOps is more than just a cool word. It's a state of mind. You must accept his values, you must help others accept his values ​​and you must constantly improve yourself and help others improve in order to be successful. As soon as you drop all your ambition and start working together, you can make people think that “DevOps” may actually sound cool.
7. Selling DevOps as a silver bullet
DevOps is like voodoo. In general, get your team of developers and administrators working together. They smoke something and then sacrifice a chicken. Once you have done this, your organization will never be the same. You will be able to deliver software faster than ever before. The configuration will be self-managing. Your deployment tools will become intelligent. Your development and administration teams recognize harmony.
Get it ... DevOps is hard work! For most, this requires a culture change! This is one of the hardest things you've ever tried. For experienced developers and administrators with whom you are trying to create it, it will be the same as getting upside down. Do not try to do it overnight, otherwise fail.
8. DevOps means developers manage combat servers.
Not! Heck no, and no again. He himself is shaking with anger that you have to read this ...
9. DevOps is development-driven release management
Let me clarify 2 things.
DevOps is not managed by development.
DevOps is not managed by administration.
If you want an environment developed by development, well, go and create one. Just do not call it DevOps. Therefore, it is not.
Take a look at this article as an example .
“In DevOps, programmers are programmers.” - Exactly!
"In the same way, in DevOps, admins are admins." - We are ready!
“Traditionally, the tasks of issuing software to a combat server are the responsibility of administrators or development teams.”
Wait a minute ...
“Administrators create deployment strategies to minimize downtime and ensure stability through flexibility and responsiveness.”
Yes, we returned to the familiar rails ... and now bang!
Release Management through Development - WTF? The situation gets worse
“Release management through development follows a different path and looks at how deployment can be carried out as often and easily as possible. However, these deployments do not necessarily occur in production ... From a process point of view, continuous delivery has two big requirements: first, the process itself must be sustainable outside of development. This means that it must be sustainable, like any process which the traditional administration team can implement. "
Not. No. Non. Nej. Na. Nee. Nein.
Development-driven can be a process. This is just not DevOps. Replacing administrators with an automated deployment process is nonsense. Please do not try this at home!
10. We can not do DevOps - We are Unique
Yes you are, yes you are my clever! But you are not so special that you cannot become DevOps. I bet you are the best developer there, the speed of your code is faster than the speed of light, and when other programmers see it, they cry for joy. Not? So, you are the most amazing Ops on the planet. If Chuck Norris were the administrator, he would be you. However, you and your organization do not have any such factor that will not allow you to implement DevOps. So let it happen to you!
Opscode's Jesse Robbins has some good tips for getting started:
- Start small - build confidence
- Create Champions
- Build trust
- Celebrate success
- Invent traditions
And useful for reading.
11. We can't do DevOps - We have bad employees.
Why do you hire them? That is why - they are awesome! If you do not think so, then you need to take a close look inside yourself, and then go and discover the real hidden talents in your team.
Someone told me recently that they could not do DevOps, because "they have the wrong developers and administrators ...". Is it that they have developers who can't write code? I thought to myself: “Bad developers work in my company - people who cannot program, they work HR and marketing!”
DevOps promotes collaboration between development and administration. This collaboration should be developed at the policy level of the entire company.
And do not say that you work "wrong" people. You just do not know how to cook them. Fight it.
12 Cooperation, when g *** about got on the fan
Okay, genius. You are about *** ***. So what? We all do it. But now you want your admin guys to get out of bed at 2 am to do a sweep of what they know nothing about. They are admins, not “cleaners,” like Michael Clayton. Wait until the error occurs during deployment to begin the interaction between developers and admins is a complete mess.
It's too late for this problem ... but maybe not for the next one. You have a team of developers and admins who communicate (or swear at 2 am) with each other, but at least they speak. Keep the dialogue constant. Get a retrospective review of what happened and how you can fix it in the future. If you are faced with this situation, then try to keep the dialogue between the teams. Open channels of communication between developers and administrators as early as possible. And then hope is not lost!
Source: https://habr.com/ru/post/170661/
All Articles