根据@jeffsusna的建议-采取以用户为中心的设计方法来处理您所做的一切pic.twitter.com/LAmHvHD4uS-CloudBees（@electricloud）2016年3月8日本周早些时候，我们主持了持续讨论视频播客，这次讨论的是ITIL和DevOps。本期节目由专家小组成员Jan Joost Bouwman（ING）、Kaimar Karu（AXELOS）、Jeff Sussna（DevOps作家和演讲者）和Simon Morris（ServiceNow）组成。在我们的讨论中，我们揭示了ITIL和DevOps之间的异同，并讨论了如何在组织中协调这两种方法的技巧。请继续阅读本周专家讨论的主要亮点、最佳实践和主要收获。想要更多的c9d9吗？每隔一个星期二上午10:00加入我们，免费观看连续讨论视频播客的现场片段。同时，您可以在这里或在我们的Youtube播放列表上观看每一个连续的讨论。此外，请务必在3月22日星期二下午5:00加入我们的"c9d9"特别节目，从移动交付日会议现场直播。专业提示：你不必遵守ITIL手册的每一页。西蒙·莫里斯说："任何一家死守手册的公司，都会走上无路可走的道路。"事实上，公司应该考虑调整任何模型——不管是ITIL、DevOps还是Agile——以满足其业务需求。换句话说，ITIL是蓝色的药丸，而DevOps是红色的药丸——如果两者都有，就同时服用。2 DevOps更像是你希望开发人员和运营部门在一个组织中如何协同工作，但它并没有告诉你如何进行运营。解决方案："看看哪些部分带来了价值并保留了它们，而那些没有产生价值的部分，就会失去它们。"——简·乔斯特·布尔曼3为什么选择ITIL？"这是解决混乱的良药，"杰夫·苏斯纳说。ITIL是一个很好的方法来控制你正在做的事情；然而，危险是当你过于专注于这个过程时。这个过程趋于僵化，与ITIL的底层服务前提失去联系。始终把重点放在服务上。它不是关于开发人员，操作，软件或服务器，而是关于服务。在考虑服务时，超越开发和操作。想想产品/设计/支持，我们如何教人们如何使用产品以及如何获得反馈。这赋予了开发产品的能力。4"实施ITIL"这个短语不应该存在——你不能这样做。ITIL应该被采纳——从心态上来说，并且适应——根据你的需要采取多少。它不是关于过程，而是关于组织能力。–凯玛卡鲁5 DevOps将人的因素从两个层面带回：1）让团队相互协作解决问题，而不是排成一队；2）专注于自动化，这样人们就可以专注于合作。——杰夫·苏斯纳6 ITIL不支持精益、敏捷或DevOps这样的学习文化——脆弱的基础设施公司很可能不支持学习文化。跟随DevOps的人更习惯于从失败中学习。——西蒙·莫里斯7直接从ITIL使用事件管理，但在sprint计划中为操作人员保留容量；例如，使用30个sprint计划来解决事件。准备投入生产的物品应该由自动驾驶室进行检查。开发人员和运营人员应该一起工作，并且应该了解其他人的技能，但是仍然有人擅长编码，也有人更善于学习。让他们各尽所能。——简·乔斯特·布曼8对于同样与DevOps保持一致的ITIL，您应该记住九件事：1）专注于价值观2）整体工作3）保持简单4）体验设计5）不断进步6）协作7）从你所在的地方开始8）直接观察9）透明。–凯玛卡鲁9当出现问题时，ITIL公司往往认为解决办法是增加更多流程。对他们来说，学习意味着："我怎样才能让人们做更多的工作来完成更多的工作？"DevOps说"让我们找到根本原因"，不管是缺乏基础设施还是可用的回滚。——西蒙·莫里斯10如果你不自动化，你永远不会成熟——这需要是第一步。不要让人做那些可以自动化的事情，这会造成糟糕的it和基础设施。–Anders Wallgren+Bonus:我不想让神经外科医生早上在下午做胸外科手术。DevOps也是一样——不要雇佣一个在一般水平上都能做到这两个的人，雇佣一个擅长这两个方面的人。–安德斯·沃格伦请观看该集的重播，了解更多信息：