历久弥新：依然适用的11条IT基本原则.docxVIP

历久弥新：依然适用的11条IT基本原则 所谓“万变不离其宗”，如今技术日新月异，无数流行语涌现——从敏捷开发、大数据分析、Docker容器到物联网、可穿戴技术再到机器学习、人工智能，这里一定有你耳熟能详的（即便你身在安全领域之外）。在这些流行语的掩盖之下，合理的IT战略基本原则仍然存在且适用。 下面是11条与时代一起发展、保持不变的老式IT原则。 1. 开源产品和专有产品一样好，甚至更好； 旧版本：“没有人因为购买IBM而被解雇”（IBM曾经的广告语）； 新版本：开源可以提供相同的优势；? 你购买的技术对你来说是一项长期承诺，但同时你也需要将其视为供应商的长期承诺。? 为了安全起见，人们过去习惯从大型供应商处购买IT产品和服务。至于现在？开源不仅可以提供相同的安全保证，甚至有时候你还可以从IBM或其他大型供应商处获得这些开源技术。 这并不是说所有的开源技术都具有足够广泛的支持基础，但是很多还是可以的。例如，如果PHP具备足够广泛的支持基础，你还会考虑继续使用具有糟糕安全记录的Java吗？然而，作为世界上最大的软件公司之一的Oracle却支持Java（与其说“支持”，不用说“提供”更为准确）。 使用开源技术其实算不上什么新鲜事了，毕竟，类似开源的SHARE库可以追溯到上世纪70年代。 2. 良好的信息安全始于良好的物理安全性 旧版本：锁好你的硬件 新版本：你的数据中心可能并不在你上锁的房间里 过去，我们始终让硬件处于锁定状态，限制少量特权员工访问数据中心，并保留有关何人进入以及何时进入数据中心的自动日志。只是现在，并非每个上锁的房间都是我们自己的房间。 特别是对于中小企业而言，出现了许多替代方案，从co-lo（Colocation主机托管的简称，指的是大型数据中心将空间租借给第三方，让他们放置自己的服务器和其他网络设备）设施到全云。 但是，不要因为没有建立自己的数据中心而节省所有的费用。你可以将其中的一部分费用投资到与你的异地提供商的低延迟、高带宽的网络连接中。更好的选择是：应用另一条古老的原则——“有备无患防患未然”。建立两个连接点，这样一来，就不会因为一条连接故障而造成业务中断的局面了。 3. 了解威胁 旧版本：库存安全威胁和实施对策 中期版本：锁定桌面并保护外围设备 新版本：加固资产，同时保护外围设备 过去，安全威胁主要是物理上的威胁，其主要源于对系统之间连接的保护不足所致。针对这种情况，我们需要通过锁定台式机并使用越来越复杂的防火墙保护周边进行防护。 时至今日，许多人仍然认为最好的对策就是锁定一切，不要让任何人发挥创造力。但是，企业的生死又往往取决于创新能力，而创新不仅仅意味着即将面世的新产品，它还意味着企业中的任何地方都必须具备创造性思维以及实践这种创新思维的能力。 如今，我们应该花更多的时间来强化资产而不是外围，甚至需要花费更多的时间来积极支持用户，因为最大的威胁是不被允许进行创新的劳动力。 4. 测试软件不仅仅意味着将代码投入生产并看看会发生什么 旧版本：维护三个环境——开发、测试、生产 新版本：将大量测试移至云端 回归（Regression）和压力测试将专业人士与业余爱好者区分开来。回归测试是一种系统范围的测试，旨在确保系统某个部分的微小变化不会破坏系统中其他地方的现有功能。而压力测试是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。 专业的IT至少需要维护三个环境——开发、测试和生产。这意味着需要花费大量时间和金钱来搭建、支持以及维护所有这三个环境。 现在，即使维护自己的数据中心，在云中启动测试环境通常也更有意义，因为你只需在需要时付费即可，省去很多额外的投入。它会根据你的生产环境，很好地进行回归测试。至于压力测试？目前还没有合适的选择，因为变量实在太多，至少暂时是这样。 5. 控制对生产环境的变更 旧版本：正式的变更控制流程 新版本：正式的变更控制流程 开发人员可以将他们的新代码直接投入生产的日子已经过去很久了。现在，想要新代码投入生产必须要经历一系列测试过程。说实话，没有人真正喜欢这个过程，但这又确实是个不可或缺的过程。这是为了确保变更不会扰乱生产，如果它确实破坏了生产，那必须确保要有一个后备计划。 想一下，云改变了这一切吗？确实如此。它使变更控制变得更加困难，因为现在，如果你不小心管理你的云提供商，他们可能会在不经过你的流程的情况下，将他们的变更引入到生产中。毕竟，基础设施是他们的。 6. 瀑布模型应该起作用，但敏捷实际上更高效 旧版本：业务经理和程序员之间的非正式交互 新版本：敏捷：不遵循任何一种线