互不兼容的编程语言、有限的管理功能、断电——IT生涯中这些问题与挫折实际上最有培训的潜力。

当所有事都运行正确，人们就学不到东西啦。当事情变坏时，真正的学习才开启。

这句俗语在军队、竞技组织与IT中都能套用。就拿VMware vSphere为例吧。当你的组织安装了它，团队真正学到东西了么？当然，你可能有些培训，你学到诸如网络配置与虚拟机设置所在的位置这类知识。但你真正学习是什么时候？对于我来说，真正的学习开启于一个存储阵列不能在vSphere环境中运行的时候。或者是时候需要我们克隆虚拟机的快照，但这在vSphere的图形用户界面中找不到选项。在那一天，数据中心真正在学习强大的PowerCLI，这简直打开了学习的大门，通往新鲜世界。

问问你自己某事错误时发生了什么。我们就说某个重要的业务流程通宵没运行吧。你的团队可以修复么？或者你需要一个顾问或打个支持电话？电话后又该咋办？你的组织在知识库或维基百科记录该修复及其相关步骤么？以便该信息在未来还可能用到，或者你只是开心问题修复就完事了？发生问题时是否受到诸多指责？或者是受到了冷静地专业地处理？

组织处理故障的方式显示了其企业文化。有些组织处理故障不得当，管理者对着下面的人乱吼一气，并在中途炒人。这样的行为方式能够延长或缩短断电么？这能告诉（潜在的）雇员为你卖命工作么？雇员还会继续在该组织效劳么？我知道有些组织的雇员非常害怕因为某事而受到责备，导致他们都不敢使劲给系统打安全补丁。依赖现有的没有大量安全问题的系统就好，而不会去冒险与创新。

有些IT团队在遭遇失败时就怯场了。他们不知道该做什么从哪入手，所以啥都不做。可能问题会自己修复，或者某人会站出来搞定问题。有些人有些时候会跳出IT，去云中寻求答案。这也是不对的，因为影子IT开支应该不惜一切避免。不再存在的某个组织最终成为笔和纸，因为其存货系统随着时间推移而遭受破坏。是的，只有笔和纸可用。没有影子IT，也没有公司。

我最喜欢的组织类型是将失败当做数据中心培训的机会。他们的责备发生在中途，甚至事后的项目分析总结，因为防御性强的人还不能敞开心胸去学习。这些组织关注问题本身，团结起来解决问题。这归结于专业与诚实，但大家坦率讨论问题并得到解决方案。

实验与故障是作为数据中心新部署与升级的激励部分而存在。这种类型的故障不应该看作是风险或阻碍，而是找到最佳前进道路的方式。这种理想化的组织也会拥抱DevOps，快速学习软件开发理念。雇员可以学习如何制定好的决策，承担预期风险，然后他们成功了。

现在你对照下你自己的组织吧。它愿意鼓励承担风险，少些责备？还是它没有希望了，那你还愿意待着？