Merge pull request #15676 from lujun9972/add-MjAxOTA5MjcgMTAgY291bnRlcmludHVpdGl2ZSB0YWtlYXdheXMgZnJvbSAxMCB5ZWFycyBvZiBEZXZPcHNEYXlzLm1kCg==

自动选题: 20190927 10 counterintuitive takeaways from 10 years of DevOpsDays
This commit is contained in:
Xingyu.Wang 2019-09-29 14:04:09 +08:00 committed by GitHub
commit de5942ed15
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 229 additions and 0 deletions

View File

@ -0,0 +1,146 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (10 counterintuitive takeaways from 10 years of DevOpsDays)
[#]: via: (https://opensource.com/article/19/9/counterintuitive-takeaways-devopsdays)
[#]: author: (KrisBuytaert https://opensource.com/users/krisbuytaert)
10 counterintuitive takeaways from 10 years of DevOpsDays
======
DevOps veteran Kris Buytaert, who was there at the founding of
DevOpsDays, shares lessons learned that might surprise you.
![gears and lightbulb to represent innovation][1]
Ten years ago, we started an accidental journey. We brought together some of our good friends in Ghent, Belgium, to discuss our agile, open source, and early cloud experiences. [Patrick Debois][2] coined the event #DevOpsdays after [John Allspaw][3] and [Paul Hammond][4]'s talk from Velocity 2009, "10+ deploys per day: dev and ops cooperation at Flickr" (which is well [worth watching][5]).
![Celebrate 10 years of DevOps Days where it all began: Ghent][6]
Now, 10 years later, the world is different. DevOps is everywhere, right? Or is it really? I have been going to [DevOpsDays][7] events since that founding, and I have learned quite a lot from my experience. Here are 10 takeaways I hope you can learn from as well.
### 1\. There is no such thing as a DevOps engineer.
Plenty of people now have "DevOps engineer" as a job title, and lots of them don't like the title. The title gives the false impression that DevOps is a job that a single "DevOp" can achieve. Most often, a DevOps engineer is a Linux engineer who, if they're lucky, does a little bit of automation. When recruiters start looking for a DevOps engineer, applicants need to ask themselves the right questions, starting with: "What does the company actually need from an applicant?" Are they looking for a build engineer, a senior developer who understands non-functional requirements, a senior operations person who can automate things, or something else entirely? Most often, what they are really looking for is someone who will turn their eyes away from the lack of agile principles in practice.
In an organization with a lot of DevOps engineers, it very often means that no DevOps is happening. A DevOps title is a sign of a new silo, and an applicant could make good money and learn new skills on the job, but they will not be "doing DevOps."
### 2\. There is no such thing as a DevOps team.
In the early days, we often said DevOps is about removing the walls of confusion between different teams, developers, and ops, about breaking down the silos. Yet somewhere along the journey, we saw a new phenomenon: the rise of the DevOps team.
"DevOps team" sounds like a new practice, but the inconsistencies across organizations are clear. In one organization, it's the team in charge of tooling, in another, it literally is the silo between the dev and the ops teams—a silo that creates more confusion, more frustration, and less collaboration. In the best of cases, it occasionally is the cross-functional team with end-to-end responsibility for the service they are building. Those teams typically prefer not to be called a DevOps team.
Calling a team "DevOps," I have found, will likely hinder the outcomes you're aiming for with DevOps.
### 3\. There is no such thing as a DevOps project.
A "project" by nature is finite. It is something you build, deliver, and then move on from. A consistent theme from 10 years of talks is that DevOps is about continual improvement, and continual improvement is never complete. Similarly, the output of these supposed projects are long-term _services_, and a service is something you build, deliver, and keep running.
It's only after we think about how services extend beyond projects that we start to see the things that are easily forgotten: non-functional requirements (NFRs). NFRs include functionality that does not fit neatly into a specific behavior. NFRs define how we judge the operation of a system. They often include all the "-ilities" you hear around DevOps: securability, reliability, usability, maintainability, and scalability. All of which are essential to the business outcome.
There is risk in the lack of empathy needed to think in short-term projects. When you have moved on to another project, you won't be as concerned with NFRs, since you're busy with a new challenge and it's someone else's problem now. However, when you run a service, you do care, and it is in your best interest to reduce the friction to keep things running smoothly.
### 4\. There is no such thing as a DevOps tool.
While many vendors will try to [sell you one][8], even the ultimate one, DevOps is not about tooling. It is about humans and collaboration. Some tools help people collaborate; often they give people with different backgrounds a shared terminology and a shared ecosystem; but equally often, the popular tools work against collaboration.
A tool-focused culture is one that can isolate people more than it helps them collaborate, as people become obsessed with their toolchain and distance themselves from those not using it. While technically, they might be awesome tools and help us in some areas, a bunch of the new, so-called DevOps tools have widened the gap between different groups. For instance, I often hear "it works in my container" is a statement that developers make to define that "their" work is done. Containers alone do not solve the collaboration challenges needed to run applications effectively. We can't let tools become the new silos.
### 5\. There is no such thing as DevOps "certified."
No multiple-choice test can confirm that you, as an individual, collaborate with your colleagues. Organizations that offer certifications may have the most excellent advice on technology and even principles of collaboration, but a certificate cannot show that someone is good at DevOps.
It is unfortunate that management teams require certificates in something we can't be certified in. Be educated in your favorite software, hardware, or cloud. Attend a local university and read the books that will educate you, such as those by [Deming][9], [Forsgren][10], [Humble][11], and [others][12]. But don't expect to become excellent at DevOps from a certification; it's more important to work with your coworkers.
### 6\. There is no such thing as a DevOps pipeline.
"Is the DevOps done yet?" "The DevOps pipeline is running." "The DevOps pipeline is broken." Whenever I hear these statements, I wonder how we got to such a term. Did we just rebrand a delivery pipeline, or is it because some companies are starting DevOps teams that manage the infrastructure for the pipeline? Or is it because the developers call the ops when the pipeline is broken?
While introducing continuous integration and continuous delivery (CI/CD) principles has a huge impact on an organization, the "DevOps pipeline" term is used in a way that I see as blame-inducing. Ops teams are at fault when the dev's pipeline is broken. Dev teams don't worry about failing pipelines as long as they wrote tests.
The concept is also misleading. Pipelines are aligned to a service or application, not to all of DevOps. When we generalize pipelines, we run the risk of encouraging silos between teams, which will leave us far from the goals of DevOps.
What I do recommend is what I've seen in hundreds of organizations across the world: Call the pipeline for Application X the Application X pipeline. This way, we'll know what application has trouble getting through its tests, getting deployed, or getting updated. We will also know the team responsible for Application X, which will be busy trying to fix it, maybe with some help from their ops friends.
### 7\. There is no such thing as standard DevOps.
The toughest news from thousands of DevOps stories across the globe is standardization. Just like we can't certify people, there is also no-one-size-fits-all standard; every organization is on a different step in their journey, a different journey than other organizations. There is no magic recipe in which you implement a number of tools, set up a number of automated flows, and suddenly you are DevOps.
A standard DevOps would mean that you implement a recipe, and suddenly the organization starts to collaborate, drops office politics, improves quality, increases morale, and is on the fast track to higher earnings with fewer outages.
DevOps is better understood as a body of practice similar to [ITIL][13]. Remember the L in ITIL stands for Library, a library with best practices to cherrypick from—not an instruction manual. Lots of the hate against ITIL came from those (failed) implementations that took the library as a detailed instruction manual. Standardized DevOps will bear the same fruits.
### 8\. There is no such thing as DevSecOps.
From the very beginning in 2009, we started DevOpsDays as a place to invite everybody. Sure, the initial battleground was visible with developers and operations people, but everybody was included: database administrators, testers, business, finance, and, yes, also security. Even as early as 2012, we were giving talks at [OWASP][14] meetups, evangelizing what we did. We joked that the "s" in DevOps stood for security, just like the "S" in HTTPS.
DevOps is inherently about security. I have found the greatest success in organizational adoption of continuous delivery comes from security teams. CD is a security requirement: you _need_ to have the ability to deploy whenever you want so that you can deploy and upgrade when you need to for business or security reasons.
On the one hand, it is sad that we have to invent a word to get the security folks included. On the other hand, it's good to have the discussion again. Fundamentally, there is no difference between DevSecOps and DevOps. Security has always been part of the development and operations mindset. I'll call it DevSecOps if that helps, but it's okay to just call it DevOps.
### 9\. There is no such thing as a finished DevOps transition.
Have you ever seen an organization that said, "We'll do the DevOps project in Q4, and by next year we'll be DevOps"—and succeeded? Neither have I.
Software delivery never stops, technology always changes, maintenance will be required, and—ideally—the DevOps mindset stays around. Once you have improved your delivery approach, you will want to keep improving. It won't be because your application is feature-complete or that the ecosystem it lives in has stopped evolving. It will be because the quality of your work improves exponentially, and many experience a similar improvement in their quality of life. DevOps will continue long after someone calls the effort "done."
### 10\. There is such a thing as DevOops.
Unfortunately, many people have not caught onto the importance of collaboration. They, often unintentionally, build silos, hold tools in higher regard than practices, require certification, and believe all the other nine takeaways. And they will struggle to succeed in a way that I like to call DevOops.
To DevOops is to hold the tools and the silos in higher regard than the principles of DevOps that will improve your work. May we all be more DevOpsy and less DevOopsy.
### The main takeaway
Throughout the 10 years of DevOpsDays events, many thousands of people around the world have learned from each other in a collaborative and open environment. Some concepts that I find to be counter to the goals of DevOps and agile are popular. Stay focused on making your services run well at your company, and learn along the way. That won't mean a copy-and-paste effort of tools or dashboards. It will mean focusing on continually improving in every way.
Good luck, and I hope to see you at the 10 year celebration at [DevOpsDays Ghent October 29-30th][15]. We have a great line up of speakers, including: 
* [Patrick Debois][2] will talk about [Connect all the business pipelines][16]
* [Bryan Liles][17] on [Sysadmins to DevOps: Where we came from and where we are going][18]
* [Bridget Kromhout][19] on [distributed DevOps][20]
* [Ant Stanley][21] on [how serverless design patterns change nothing [for DevOps]][22]
* [Julie Gundersen][23] on [being an Advocate for DevOps][24]
See you soon, back where it all began.
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/9/counterintuitive-takeaways-devopsdays
作者:[KrisBuytaert][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/krisbuytaert
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/innovation_lightbulb_gears_devops_ansible.png?itok=TSbmp3_M (gears and lightbulb to represent innovation)
[2]: https://twitter.com/patrickdebois
[3]: https://twitter.com/allspaw
[4]: https://twitter.com/ph
[5]: https://www.youtube.com/watch?v=LdOe18KhtT4
[6]: https://opensource.com/sites/default/files/uploads/devopsdays-ghent-2019-10year.png (Celebrate 10 years of DevOps Days where it all began: Ghent)
[7]: https://devopsdays.org/
[8]: https://opensource.com/article/19/6/you-cant-buy-devops
[9]: https://mitpress.mit.edu/books/out-crisis
[10]: https://nicolefv.com/book
[11]: https://continuousdelivery.com/about/
[12]: https://itrevolution.com/devops-books/
[13]: https://en.wikipedia.org/wiki/ITIL
[14]: https://www.owasp.org
[15]: https://devopsdays.org/events/2019-ghent/registration
[16]: https://devopsdays.org/events/2019-ghent/program/patrick-debois/
[17]: https://twitter.com/bryanl
[18]: https://devopsdays.org/events/2019-ghent/program/bryan-liles/
[19]: https://twitter.com/bridgetkromhout
[20]: https://devopsdays.org/events/2019-ghent/program/bridget-kromhout/
[21]: https://twitter.com/IamStan
[22]: https://devopsdays.org/events/2019-ghent/program/ant-stanley/
[23]: https://twitter.com/Julie_Gund
[24]: https://devopsdays.org/events/2019-ghent/program/julie-gunderson/

View File

@ -0,0 +1,83 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Microsoft open sourcing its C++ library, Cloudera's open source data platform, new tools to remove leaked passwords on GitHub and combat ransomware, and more open source news)
[#]: via: (https://opensource.com/article/19/9/news-september-28)
[#]: author: (Scott Nesbitt https://opensource.com/users/scottnesbitt)
Microsoft open sourcing its C++ library, Cloudera's open source data platform, new tools to remove leaked passwords on GitHub and combat ransomware, and more open source news
======
Catch up on the biggest open source headlines from the past two weeks.
![Weekly news roundup with TV][1]
In this edition of our open source news roundup, we take a look Cloudera's open source data platform, Microsoft open sourcing its C++ library, new tools to beef up digital security, and more!
### Cloudera releases open source cloud data platform
It was only a few months ago that data processing software vendor Cloudera went [all in on open source][2]. The results of that shift have started to appear, with the company releasing "[an integrated data platform made up entirely of open-source elements.][3]"
Called Cloudera Data Platform, it combines "a cloud-native data warehouse, machine learning service and data hub, each running as instances within the self-contained operating environments." Cloudera's chief product officer Arun Murthy said that by using "existing components in the cloud, the platform cuts deployment times from weeks to hours." The speed of open source adoption is a great industry proof point. One can image the next step is Cloudera's participation in the underlying open source communities they now depend on. 
### Microsoft open sources its C++ standard library
When you think of open source software, programming language libraries probably aren't the first things that come to mind. But they're often an essential part of the software that we use. A team at Microsoft recognized the importance of the company's implementation of the C++ Standard Library (STL) and it's been [released as open source][4].
By making the library open source, users get "easy access to all the latest developments in C++" and enables them to participate "in the STLs development by reporting issues and commenting on pull requests." The library, which is under an Apache License, is [available on GitHub][5].
### Two new open source security tools
Nowadays, more than ever it seems, digital security is important to anyone using a computer — from average users to system administrators to software developers. Open source has been playing its part in helping make systems more secure, and two new open source tools to help secure an organization's code and its computers have been released.
If you, or someone in your company, has ever accidentally published sensitive information to a public GitHub repository, then [Shhgit is for you][6]. The tool, which you can [find on GitHub][7], is designed to detect passwords, connection strings, and access keys that wind up being exposed. Unlike similar tools, you don't need to point Shhgit at a particular repository. Instead, it "taps into the GitHub firehose to automatically flag up leaked secrets".
Ransomware attacks are no joke, and defending against them is serious business. Cameyo, a company specializing in virtualization, has released an [open source monitoring tool][8] that "any organization can use to identify attacks taking place over RDP (Remote Desktop Protocol) in their environment." Called [RDPmon][9], the software enables users to "monitor and identify brute force attacks and to help protect against ransomware". It does this by watching the number of attempted RDP connections, along with the number of users and which programs those users are running.
### New foundation to develop open source data processing engine
There's a new open source foundation in town. Tech firms Alibaba, Facebook, Twitter, and Uber have [teamed up][10] to further develop Presto, a database search engine and processing tool originally crafted by Facebook.
The Presto Foundation, which operates under the Linux Foundation's umbrella, aims to make Presto the "fastest and most reliable SQL engine for massively distributed data processing." One of the foundation members, Alibaba, already has plans for the tool. According to an [article in CX Tech][11], Alibaba intends to refine Presto to more efficiently "sift through the mountains of data generated by its e-commerce platforms."
#### In other news
* [Scientists Create Worlds First Open Source Tool for 3D Analysis of Advanced Biomaterials][12]
* [Percona announces Percona Distribution for PostgreSQL to support open source databases][13]
* [Sage gets cloudy, moves towards open source and microservices][14]
* [Compliance monitoring of EUs Common Agricultural Policy made more transparent and efficient with Open Source][15]
* [WebLinc is taking its in-house ecommerce platform open source][16]
_Thanks, as always, to Opensource.com staff members and moderators for their help this week._
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/9/news-september-28
作者:[Scott Nesbitt][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/scottnesbitt
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/weekly_news_roundup_tv.png?itok=B6PM4S1i (Weekly news roundup with TV)
[2]: https://opensource.com/19/7/news-july-20#cloudera
[3]: https://siliconangle.com/2019/09/24/cloudera-debuts-open-source-integrated-cloud-data-platform/
[4]: https://devclass.com/2019/09/18/microsoft-turns-to-github-to-open-source-c-stl/
[5]: https://github.com/microsoft/STL
[6]: https://portswigger.net/daily-swig/open-source-tool-for-bug-hunters-searches-for-leaked-secrets-in-github-commits
[7]: https://github.com/eth0izzle/shhgit/
[8]: https://betanews.com/2019/09/18/tool-prevents-brute-force-ransomware/
[9]: https://github.com/cameyo/rdpmon
[10]: https://sdtimes.com/data/the-presto-foundation-launches-under-the-linux-foundation/
[11]: https://www.caixinglobal.com/2019-09-24/alibaba-global-tech-giants-form-foundation-for-open-source-database-tool-101465449.html
[12]: https://sputniknews.com/science/201909111076763585-russian-german-scientists-create-worlds-first-open-source-tool-for-3d-analysis-of-advanced/
[13]: https://hub.packtpub.com/percona-announces-percona-distribution-for-postgresql-to-support-open-source-databases/
[14]: https://www.itworldcanada.com/article/sage-gets-cloudy-moves-towards-open-source-and-microservices/421771
[15]: https://joinup.ec.europa.eu/node/702122
[16]: https://technical.ly/philly/2019/09/24/weblinc-ecommerce-platform-open-source-workarea/