在IT中，有很多令人喜欢的框架，无论敏捷，ITIL，精益，COBIT，六西格玛或其他，其实这些背后都是透着对“***实践”指导的渴望，这种渴望不可替代。
“***实践”的概念本身是一种谜。 谁能决定一个实践是否真的是***的? 最适合谁? 尽管在大多数框架中都倡导“采纳和适应性”，但依然存在着针对已发布的***做法进行不断调整和优化。 无论是为了推动“***的”，“***”还是“***实践”，许多组织都将这些术语作为某种形式的竞争优势。
是不是真的? 难道业务结果不应该是真正的竞争优势，并衡量IT实践是否真的是满足客户要求的“***”?
DevOps研究所成立于2015年，作为新兴DevOps实践的全球学习社区。 自推出以来，我们有意避免提及DevOps“***做法”。
我们认为DevOps的做法不断涌现，在许多情况下，它们在颠覆被证明。
通过研究、访谈、专业会议和我们的董事和合作伙伴的经验，DOI的目标是通过知识，教育和认证模式识别，捕获和共享新的DevOps实践，这些模式最适合学习社区和企业IT。 当成功的DevOps所需的专业知识和掌握程度不明确并且可能不适用于一个人时，我们认为将个人认证为“专家”或“大师”为时过早。
DevOps相当年轻。 它没有一个单一的知识体系。 对其哲学，运动或框架的表述依然还存在分歧。 尽管如此，DevOps正在跨越从创新者到幼小生命体的鸿沟，比任何其他IT框架更快。 为什么? 也许这是因为DevOps谈到许多IT长期积累的文化和技术挑战，并寻求解决方案。
所以我们不是专注于***实践，而是同意DevOps的核心原则：
- Go faster(跑得更快)
- Shorten feedback loops(缩短反馈环)
- Experiment and learn(实验和学习)
- Cultural transformation(文化转变)
- Deliver business and customer value constantly and consistently(持续且一致性的交付商业和客户价值)
毫无疑问，一些实践或者称之为做法已经明显浮出水面，对于实现DevOps的核心原则至关重要：
- Agile software development(敏捷软件管理)
- Continuous integration(持续集成)
- Continuous delivery pipelines(持续交付流水线)
- Automated and continuous testing(自动化和持续的测试)
- Proactive monitoring(主动监控)
- Improved communication and collaboration(改进的沟通和协作)
不过，过去一年，DOI还根据额外的做法作了一些补充：
- DevSecOps/rugged DevOps(DevSecOps和坚固的Devops)
- ChatOps
- Agile service management(敏捷服务管理)
- Lean(精益)
- Immersion practices (Garage, Lofts, Dojos)沉浸式实践()
- DevOps teams(DevOps团队)
明年会出现什么? 谁知道 - 但这是DevOps的激动人心的部分。 随着时间的推移，矛盾越来越少，完善得越来越丰富。 每个新兴的实践似乎是完善和微调之前的事情。
即使没有一个标准的定义，DevOps已经鼓励组织检查他们的当前特有做法，查明差距，评估其自动化，最重要的是进行协作讨论。 变革已经播下种子，但没有明确的***实践。 棒极了! 我们不要通过附加一套静态的***实践来扼制动力。
最终会达成DevOps的***做法吗? 也许。 DevOps几乎涉及IT管理的各个方面 - 人员，实践和自动化。 这就类似于一整套的***实践。 当然有些人会尝试发布他们的“确定”版本，用来描述DevOps知识体系。 即使是“DevOps手册”，这是今年晚些时候出版的一本重要的图书，它是DevOps运动的许多早期创始人之间的合作努力。 他们的观点和洞察力将是非常棒的，但没有限制。
我知道缺乏一套知识和成文的***实践令人沮丧。 在过去的框架中，知识体系既是一种有用的工具，也是限制性的，知识内容很难保持现状。 对于DevOps，让我们通过推动一个有兼容性和集体性的新兴实践知识体系，从而真正拥有分享、协作和持续创新的真正精神。
如果我们确定了一套DevOps***实践，我们是否真的会抑制我们试图坚持的价值观? 我希望不是。
【本文是51CTO专栏作者“王津银”的原创稿件，转载请注明出处】
