Impressions of the 2013 DevOpsDays Mountain View Conference
The conference ended just a few hours ago, so there is still a little confusion in the head on the quantity and quality of the information received. Hopefully, by writing this post I’ll get to understand my own thoughts. First there will be general impressions, then briefly go over the reports and finish with thoughts on what was said at the conference, the benefit of such thoughts accumulated along the way decently. Want to know what they are talking about in the world of DevOps? Then you under the cat. And yes, the post will be long, but in the end there will be a bonus surprise).
What I want to say at once - it was a conference that the engineers did, for engineers and only engineers also spoke at it. Even among representatives of vendors, such as OpsCode or PuppetLabs, there were no bores from marketing and sales departments. That is why there was an adequate attitude towards them, we communicated with them a lot and tightly, and not as usual. For the same reason, there were no girls and hr in miniskirts colored by body art. All this created a really cool atmosphere for a thermal lamp conference. By the way, there were about 300 people on it, but this did not stop communicating with anyone you want. Solid positive in general.
I would like to tell you about the conference format: 1 hall, 4 reports, 6 iginite talks for 10-15 minutes and then open space. Because of this format, everything was very dynamic, everyone had time for all the reports, and most importantly - had the opportunity to talk on topics that you really care about at the moment, and not listen to another report from the category of “what we are great”, Such By the way, there was not one.
I would also like to note a really important thing - at the engineering conference, their 20 reports and ignite talks, only 2 were devoted to tools. In all the others, it was about processes, culture, practices and people. A pleasant thing to my ear - in two days no one called people resources. We would be the same!
')
Now actually run through the reports. The program is available at this link , and reports and video over time will be posted centrolized, But back to the reports.
He started the conference Jesse Robbins - a former firefighter, and, in terms of compatibility, co-founder of Opscode. Jesse talked about a fairly simple, but unfortunately not an obvious thing for everyone - the transition to devops is a business necessity, and not the desire of engineers to get a prefix for their position. And if this is not the case, problems await you. In general, Jesse talked about the transformation of enterprise companies using agile and devops values . And the key idea of ​​his report on how large companies are trying to transform themselves into modern and high-performance organizations. Imagine that a company is an elephant, and the goal of transformation is to learn how to fly. So, many companies are trying to start waving their elephant ears to take off. The result can be presented. To learn how to fly you need wings, the right energy and a place to take off. Therefore, the transformation of such companies into something really worthwhile is a long and complex process in which you need to grow your wings and lose excess mass. For me, this report was key throughout the conference, because it reflected the real essence of devops.
After Jesse, the word passed to Jeff Sussna , who talked about what few people say - where is the role of QA in devops . In a nutshell, the task of QA is to pull the head out, sorry, from the ass and start watching, and most importantly, tell everyone what they see in the application from the point of view of the real world and real users, the application works in the combat system, as well as in work business. By and large, the same QA should do the same thing in Agile, in devops it is also necessary to understand the infrastructure and think about automating the delivery, and not just its corner of the pioneer, or rather functional tests. In general, Jeff gives me a big plus into karma because this is another person who is trying to wake the sleeping testers.
After the break, J.Paul Reed took the microphone into his own hands and told about the organization that makes 120 thousand deliveries a day. This organization is the FAA - Federal Aviation Administration, the Federal Aviation Administration, which successfully completes those 120,000 flights within America on the day. Paul made a smart parallel between what the FAA does and how the development process should be built. In this case, the developers become pilots, and operations - dispatchers. We add a number of practices, such as this - if a star comes in the system, we honestly admit it and rake it, no matter what rules we set. And this is the common task of all team members. And so that the stars would not be announced too often, we do a post-mortem. In the report, Paul had a cool visualization of how FedEx dispatchers handled a situation when a storm was covering the whole of America, and how airplanes behaved at this time. Visibility is impressive . We are waiting for the slide.
At the beginning, I took the fourth report as a marketing bullshit, because they talked about what great thing they had come up with so that girls could join IT. The project is called http://www.hackbrightacademy.com and it is really cool, but I really didn’t want to hear about it, until we raised such a topic as mentoring and hiring staff in general. And it was a really cool topic and that is why. In many companies, there is an acute issue of hiring staff, but at the same time, they have little thought about how to integrate people into the process that has the process, and most importantly, give them the same set of values ​​that the team has. So, the solution to this problem is mentoring, and not formally - I am a mentor, okay, but full-fledged, for which the employee’s time is allocated. And an important component is not just the training of practitioners, but also the transfer of values, the adjustment to the desired mindset. So people are really built into teams. And also: “Speak to the“ why ”of what your Jr. Engineers are in the future. ”In general, many companies have a note.
I will not describe in detail about ignite talks - wait for the video and see, there were really cool reports. The brain blew up)
The second day of the presentations began with one of the organizers = Damon Edwards, who talked about how to build a devops culture in the company. The whole presentation is very cool, but I would like to highlight one main idea. If you want to become a company that can competently deliver a product - make sure that the whole team understands how the company develops and earns. And also loses, fakapit and stuff. To do this, you have two useful tools: Value Stream Map (within which you need to do both timeline analysis and waste analysis) and metrics toolchain (building a chain of metrics from business to each final person in the company). Ultimately, everyone must understand their role in how a company lives in the market and earns a profit. Every time I try to communicate these things when I talk about devops, including at the #devops training. And every time I definitely hear the phrase that “the time of our programmers is too expensive to spend on such meetings - they have to write code”, “the programmer / tester / admin should not know about it, it’s not allowed” and of course the phrase is about people -resources. If you belong to the last group, then I have a picture for you.
After Damon, it was Toufic Boubez 's turn, which touched on such an important thing as monitoring and why the #monitoringsucks tag was used so actively for a long time. So, you set yourself a monitoring tool, took a guide and set it up on it. Have you got monitoring? Hrenushki! You have a system that eats a bunch of resources and makes everyone nervous. So, a very simple idea of ​​the report - if one of the metrics is never analyzed, it should be sent to the furnace. To prevent this from happening, all the metrics should be tied to events in the system - deposits, reconfigs, releases of new features, and so on. Won't do that - your monitoring sucks! The second simple thought is that instead of blindly following the guidelines, set up 1-2 metrics at the very beginning for what hurts the system — JVM, CPU, disc I / O, and so on. And you will be happy.
Then came the report of comrades from the highly respected Thoughtworks company, from Scott Turnquest , who said that if your development process is stupid and slow, only its members can improve it. To do this, they must raise their backsight points, build a Value Stream Map, Ishikawa diagram, or at least 5 Whys to find solutions to root problems, which are solutions, then you just need to take and implement. It sounds as usual simple, but I know from my own experience that many programmers are shaking from the thought that they will not code, but will go to a rally. Picture in the subject.
And the last of the reports from Antoni Batchelli , said that we actually live in a complex world. But this does not stop us, and we also do complex (complex) software, we put it into a more complex infrastructure, and then for a long time, how to live with all this. What Anthony ultimately wanted to say - the antonym for the complex is not easy, but simple. Which, of course, looks like an untranslatable play on words. In simple language, everything can be expressed like this - before you do something that is guaranteed to be complex, think about the smaller brothers, namely those who will work with you after this and make it so that it nevertheless is simple to use and understand. In fact, I would like to once again listen to / reconsider, because the report was complex, and on the second day the information was received more than decently.
Now I will try to summarize what was in my head. The current situation in IT is such that either you start delivering the right software, which is demanded by customers, making every effort for this, or you will be strangled by competitors, and not really straining. The idea from the captain is obvious, but the whole point is in the phrase “putting all the efforts for this”. I will try to reveal what I meant by this - it is not enough to find a cool idea, smart developers, a sly marketer and a rich investor. This is good now in bulk. The key idea is that everything, or rather even so, ALL BLE * Tb, should work transparently for each other and understand why they need each other. Further. As Anthony has already noted, we live in a surprisingly complex world, in which to survive we need to apply considerable mental efforts, but for this we need time, which we often spend on any bullshit as formal processes, bureaucracy, war between teams and so on. So, it's time to tie with this heresy, otherwise the company kapets, and you need to update your resume. This actually implies the well-known phrase “In any incomprehensible situation, evolve.” Namely: learn new skills, automate processes, change culture and so on. Too lazy to do it - let's say goodbye, you will soon be asked from this market. All this I would like to discuss in comments.
To defuse the atmosphere - some of the brightest tweets.
@ jesserobbins
Don't fight stupid. Do more awesome. <- Word.# devopsdays # cloudops
@ adrianco
Elephants can't fly by flapping their ears harder -@ jesserobbins # devopsdays
@ jonathan_thorpe
“Value co-creation is a journey”. Couldn't agree more. It seems counts# devopsdays
@ dberkholz
QA: thinking about the overall user experience beyond the product. It's about providing a service. -@ jeffsussna # devopsdays
@ wickett
ipods
@ kylesj <
there is no other "why?" than the "Why?" of the business.# damonedwards # devopsdays . yup. cool stuff! = delivering for the business
@ writerferret
Never underestimate the power of a pen and paper. You dont always need fancy tech# DevOpsDays
@ jondecamp
" If you’re a computer, you can’t make it all the computers and all the computers."# Devopsdays
@ benzobot
“When it gets to get it in the way.” Wise words!# devopsdays
@ vmwarecloudops
"We need to reduce the layers of abstraction."# DevOpsDays
And now the time of the promised bonus - in September of this year in Moscow (or St. Petersburg, it has not been decided yet) a DevOpsDays Russia conference will take place. I will be its organizer, so stay tuned!
What I want to say at once - it was a conference that the engineers did, for engineers and only engineers also spoke at it. Even among representatives of vendors, such as OpsCode or PuppetLabs, there were no bores from marketing and sales departments. That is why there was an adequate attitude towards them, we communicated with them a lot and tightly, and not as usual. For the same reason, there were no girls and hr in miniskirts colored by body art. All this created a really cool atmosphere for a thermal lamp conference. By the way, there were about 300 people on it, but this did not stop communicating with anyone you want. Solid positive in general.
I would like to tell you about the conference format: 1 hall, 4 reports, 6 iginite talks for 10-15 minutes and then open space. Because of this format, everything was very dynamic, everyone had time for all the reports, and most importantly - had the opportunity to talk on topics that you really care about at the moment, and not listen to another report from the category of “what we are great”, Such By the way, there was not one.
I would also like to note a really important thing - at the engineering conference, their 20 reports and ignite talks, only 2 were devoted to tools. In all the others, it was about processes, culture, practices and people. A pleasant thing to my ear - in two days no one called people resources. We would be the same!
')
Now actually run through the reports. The program is available at this link , and reports and video over time will be posted centrolized, But back to the reports.
He started the conference Jesse Robbins - a former firefighter, and, in terms of compatibility, co-founder of Opscode. Jesse talked about a fairly simple, but unfortunately not an obvious thing for everyone - the transition to devops is a business necessity, and not the desire of engineers to get a prefix for their position. And if this is not the case, problems await you. In general, Jesse talked about the transformation of enterprise companies using agile and devops values . And the key idea of ​​his report on how large companies are trying to transform themselves into modern and high-performance organizations. Imagine that a company is an elephant, and the goal of transformation is to learn how to fly. So, many companies are trying to start waving their elephant ears to take off. The result can be presented. To learn how to fly you need wings, the right energy and a place to take off. Therefore, the transformation of such companies into something really worthwhile is a long and complex process in which you need to grow your wings and lose excess mass. For me, this report was key throughout the conference, because it reflected the real essence of devops.
After Jesse, the word passed to Jeff Sussna , who talked about what few people say - where is the role of QA in devops . In a nutshell, the task of QA is to pull the head out, sorry, from the ass and start watching, and most importantly, tell everyone what they see in the application from the point of view of the real world and real users, the application works in the combat system, as well as in work business. By and large, the same QA should do the same thing in Agile, in devops it is also necessary to understand the infrastructure and think about automating the delivery, and not just its corner of the pioneer, or rather functional tests. In general, Jeff gives me a big plus into karma because this is another person who is trying to wake the sleeping testers.
After the break, J.Paul Reed took the microphone into his own hands and told about the organization that makes 120 thousand deliveries a day. This organization is the FAA - Federal Aviation Administration, the Federal Aviation Administration, which successfully completes those 120,000 flights within America on the day. Paul made a smart parallel between what the FAA does and how the development process should be built. In this case, the developers become pilots, and operations - dispatchers. We add a number of practices, such as this - if a star comes in the system, we honestly admit it and rake it, no matter what rules we set. And this is the common task of all team members. And so that the stars would not be announced too often, we do a post-mortem. In the report, Paul had a cool visualization of how FedEx dispatchers handled a situation when a storm was covering the whole of America, and how airplanes behaved at this time. Visibility is impressive . We are waiting for the slide.
At the beginning, I took the fourth report as a marketing bullshit, because they talked about what great thing they had come up with so that girls could join IT. The project is called http://www.hackbrightacademy.com and it is really cool, but I really didn’t want to hear about it, until we raised such a topic as mentoring and hiring staff in general. And it was a really cool topic and that is why. In many companies, there is an acute issue of hiring staff, but at the same time, they have little thought about how to integrate people into the process that has the process, and most importantly, give them the same set of values ​​that the team has. So, the solution to this problem is mentoring, and not formally - I am a mentor, okay, but full-fledged, for which the employee’s time is allocated. And an important component is not just the training of practitioners, but also the transfer of values, the adjustment to the desired mindset. So people are really built into teams. And also: “Speak to the“ why ”of what your Jr. Engineers are in the future. ”In general, many companies have a note.
I will not describe in detail about ignite talks - wait for the video and see, there were really cool reports. The brain blew up)
The second day of the presentations began with one of the organizers = Damon Edwards, who talked about how to build a devops culture in the company. The whole presentation is very cool, but I would like to highlight one main idea. If you want to become a company that can competently deliver a product - make sure that the whole team understands how the company develops and earns. And also loses, fakapit and stuff. To do this, you have two useful tools: Value Stream Map (within which you need to do both timeline analysis and waste analysis) and metrics toolchain (building a chain of metrics from business to each final person in the company). Ultimately, everyone must understand their role in how a company lives in the market and earns a profit. Every time I try to communicate these things when I talk about devops, including at the #devops training. And every time I definitely hear the phrase that “the time of our programmers is too expensive to spend on such meetings - they have to write code”, “the programmer / tester / admin should not know about it, it’s not allowed” and of course the phrase is about people -resources. If you belong to the last group, then I have a picture for you.
After Damon, it was Toufic Boubez 's turn, which touched on such an important thing as monitoring and why the #monitoringsucks tag was used so actively for a long time. So, you set yourself a monitoring tool, took a guide and set it up on it. Have you got monitoring? Hrenushki! You have a system that eats a bunch of resources and makes everyone nervous. So, a very simple idea of ​​the report - if one of the metrics is never analyzed, it should be sent to the furnace. To prevent this from happening, all the metrics should be tied to events in the system - deposits, reconfigs, releases of new features, and so on. Won't do that - your monitoring sucks! The second simple thought is that instead of blindly following the guidelines, set up 1-2 metrics at the very beginning for what hurts the system — JVM, CPU, disc I / O, and so on. And you will be happy.
Then came the report of comrades from the highly respected Thoughtworks company, from Scott Turnquest , who said that if your development process is stupid and slow, only its members can improve it. To do this, they must raise their backsight points, build a Value Stream Map, Ishikawa diagram, or at least 5 Whys to find solutions to root problems, which are solutions, then you just need to take and implement. It sounds as usual simple, but I know from my own experience that many programmers are shaking from the thought that they will not code, but will go to a rally. Picture in the subject.
And the last of the reports from Antoni Batchelli , said that we actually live in a complex world. But this does not stop us, and we also do complex (complex) software, we put it into a more complex infrastructure, and then for a long time, how to live with all this. What Anthony ultimately wanted to say - the antonym for the complex is not easy, but simple. Which, of course, looks like an untranslatable play on words. In simple language, everything can be expressed like this - before you do something that is guaranteed to be complex, think about the smaller brothers, namely those who will work with you after this and make it so that it nevertheless is simple to use and understand. In fact, I would like to once again listen to / reconsider, because the report was complex, and on the second day the information was received more than decently.
Now I will try to summarize what was in my head. The current situation in IT is such that either you start delivering the right software, which is demanded by customers, making every effort for this, or you will be strangled by competitors, and not really straining. The idea from the captain is obvious, but the whole point is in the phrase “putting all the efforts for this”. I will try to reveal what I meant by this - it is not enough to find a cool idea, smart developers, a sly marketer and a rich investor. This is good now in bulk. The key idea is that everything, or rather even so, ALL BLE * Tb, should work transparently for each other and understand why they need each other. Further. As Anthony has already noted, we live in a surprisingly complex world, in which to survive we need to apply considerable mental efforts, but for this we need time, which we often spend on any bullshit as formal processes, bureaucracy, war between teams and so on. So, it's time to tie with this heresy, otherwise the company kapets, and you need to update your resume. This actually implies the well-known phrase “In any incomprehensible situation, evolve.” Namely: learn new skills, automate processes, change culture and so on. Too lazy to do it - let's say goodbye, you will soon be asked from this market. All this I would like to discuss in comments.
To defuse the atmosphere - some of the brightest tweets.
Don't fight stupid. Do more awesome. <- Word.
Elephants can't fly by flapping their ears harder -
“Value co-creation is a journey”. Couldn't agree more. It seems counts
QA: thinking about the overall user experience beyond the product. It's about providing a service. -
ipods
there is no other "why?" than the "Why?" of the business.
Never underestimate the power of a pen and paper. You dont always need fancy tech
" If you’re a computer, you can’t make it all the computers and all the computers."
“When it gets to get it in the way.” Wise words!
"We need to reduce the layers of abstraction."
And now the time of the promised bonus - in September of this year in Moscow (or St. Petersburg, it has not been decided yet) a DevOpsDays Russia conference will take place. I will be its organizer, so stay tuned!
Source: https://habr.com/ru/post/184320/
All Articles