在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最佳实践，我们是否真的会抑制我们试图坚持的价值观？ 我希望不是。
