所谓“万变不离其宗”，如今技术日新月异，无数流行语涌现——从敏捷开发、大数据分析、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. 瀑布模型应该起作用，但敏捷实际上更高效
旧版本：业务经理和程序员之间的非正式交互
新版本：敏捷：不遵循任何一种线性的路径，遵循的是迭代式的开发方法
众所周知，在一个软件开发项目开始之前，项目经理的工作往往是要确定在该项目的生命周期中应该采用哪种开发方法。目前，业界比较流行的开发方法有两种，它们分别是：
瀑布模型，一种传统的开发模型与方法。
敏捷方法，一种较瀑布模型更新的、快速的应用程序开发模型，开发人员经常使用Scrum来实现。
瀑布模型为软件开发提供了更为连续的方法。它会按如下顺序进行推进：
收集软件开发的需求文档。
在需求确定完成后，开始对应用程序进行设计。
着手开发，并执行并行式的单元测试。
通过增加负载或压力，开展性能测试、以及用户验收测试，以确保系统整体的稳定性和健壮性。
测试团队将检测到的缺陷提交给开发人员，以着手进行缺陷的修复。
将应用程序部署到生产环境中。
然而，敏捷方法却并不遵循任何一种线性的路径。它遵循的是迭代式的开发方法。它不会为项目的全程创建各种任务，而是分为多个迭代周期阶段（Sprint）。因此，敏捷方法通常关注的是四个方面的基本价值：
团队成员之间的交互，而不是单纯的工具之间。
更强调持续的工作过程，而不是包罗万象的文档。
客户在每一次sprint中的合作与参与度。
快速响应变更，而不是循规蹈矩。
7. 团队关系是任何业务和流程的基础
旧版本：管理与其他高级管理人员的关系是CIO工作的关键部分
新版本：管理与其他业务的关系是每个人工作的关键部分
如今，业务不再是一群孤立的任务，而是关系的集合。有了良好的关系，一切都能正常运行，没有良好的关系，或许什么也做不了。
当企业是严格的等级制度时，CIO与其他高级管理人员建立了关系，这就足够了。如果其他顶级高管不信任CIO，IT就无法成功。就这么简单。
但是如今，高效的企业都在遵循DevOps文化，鼓励IT部门的任何成员与业务中的任何其他人进行交互和协作，以完成工作。如果业务的其余部分不信任IT，IT同样无法成功。如果建立高效的交互和协作关系，那么关于IT的一切都会更容易。记住，不是容易，是更容易。
8. 集成，因为“自动化孤岛”的互连会让很多业务流程变得愚蠢
旧版本：逐步基积累自定义编程批处理接口
新版本：带有工程实时接口的服务总线或等效产品
更新版本：与非IT驱动的SaaS解决方案集成
当人们将计算机生成的报告中的信息重新键入数据输入屏幕时，IT意识到其最重要的职责之一就是集成不同的系统以保持数据同步。
因此，它构建了很多接口。其中许多都是自定义批处理ETL（ETL，Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程）。
使生态系统中的所有软件能够互操作对于构建简化付任工作流程至关重要。但是，如今的软件种类繁多，难以维护和兼容。因此，明智的IT部门会选择投资服务总线（service bus）或类似的东西，并对其接口进行了设计，因为只是将一个堆叠在另一个之上，对于解决问题毫无帮助。
如今，IT部门之外仍然存在大量“影子IT”，主要是以SaaS（Software-as-a-Service，软件即服务）的形式由业务经理作为自动化孤岛引入。最终，他们会厌倦让员工重新输入数据。所以企业组织也要为他们的加入做好准备。
9. IT的存在是为了支持业务
老版本：不为技术而技术
新版本：提供技术领导力
IT人员的存在不应该只是为了技术本身，这会将其角色限制在处理工单上。而事实上，它必须超越这一点，并提供技术领导力。
任何未能提供技术领导力，提出有效建议和讨论，而不只是默默遵循命令的IT部门都在基础层面上面临淘汰。
技术领导力还意味着支持准备购买或构建自己技术的经理和用户。现在是时候认识到“影子IT”是一件好事，因为它增加了IT带宽。当然，也存在风险。毕竟，任何值得做的事都具备风险。
IT必须帮助企业中的每个人利用他们的所有技术取得业务成功，而不是扼杀任何“来历不明”的东西。
10. 项目需要计划
旧版本：瀑布模型意味着不同的时期、阶段、最后期限和里程碑；
新版本：即便有了敏捷，项目也需要最后期限和里程碑；
瀑布模型不会失败，因为它们具备有序的计划；然而它们又是失败的，因为现实世界中的项目始终使不断学习和练习的，而不是从高级要求到详细蓝图的有序计划。
而敏捷就可以很好地应对这种持续学习的现实需求。这并不意味着业务主管可以批准不提供范围、工作量和预算估计的项目建议。它意味着人们必须接受持续学习，也就是说，计划不会被固定，也不应该被固定——其应该不断发展以适应团队对形势不断变化的认知。
当然，在没有戏剧性变化的情况下，瀑布模型同样是可以发挥现实意义的。
11. IT的存在是为了业务变革，否则意义何在？
旧版本：IT是整个业务变革的主要驱动力
中期版本：IT是业务变革的最大障碍
新版本：IT是整个业务变革的主要驱动力
当计算机焕然一新时，企业高管便希望通过它们使业务流程变得更快，更便宜，同时以减少人为错误的方式来推动各领域的变革。
这种期待一直持续到IT必须支持如此多的互连系统，以至于做任何新操作都变得十分耗时，昂贵且有风险。即便是依赖瀑布方法也无济于事。
不过，这种情况最终还是扭转了。在敏捷以及更好的集成工具的多重助攻下，IT开始重新推动变革，而不再是其最大的障碍。
声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
