国产化替代：资源有限的甲方如何选择操作系统？
信创的时间表，估计行内已经无人不知了。倒计时进行中必然出现各种压枪抢跑和弯道超车，公众号上各种嘴炮、尬吹、互捧甚至指着鼻子对骂，一如菜市场小贩们为了争夺买菜大妈那不多的几块钱菜金而撕破脸皮。
笔者：国际认证信息系统审计师、软考系统分析师、软件工程硕士
只是在我看来，连自己能力背景（看上面）都不敢晒出来的公众号，又能有多少可信度，甚至某些个人号还可以大幅度跨界，无论上天入地任何国产化领域他都懂，厉害厉害，佩服佩服。
之所以谈选择操作系统，相信读者都清楚。操作系统是信息技术软件环境的基石，对于信息系统是硬件之上的第一层。正确选择对自己合适的操作系统是信息系统建设过程的第一关。
一些公众号的内容着重于从软件质量的个别要素对国产操作系统进行评价。对此我只能摇头。
我自己曾经做了4年的软件测评，当年是基于现已废止的 GB/T 16260 系列标准做软件质量评价。有这样的经验在前，我非常清楚软件测评是严谨的评价过程，几千字的公众号文章根本不可能真正评价什么。
另一些文章集中于从技术特性角度讨论选择的可能性。这是会有一部分的甲方会关注，但实际上大部分甲方尤其是资源有限的甲方群体根本就不关心。
资源有限，意味着包括预算充裕度、技术水平、实施能力等等都不足。
换个角度说，如果乙方不是同样从资源有限的角度协助甲方选择实现国产化替代的产品和实施过程，那么这个乙方就是不合格的，扯多少产品的技术底蕴实际都是无意义的。
所以选择依据的第一点就是：
也就是，如果被评估的操作系统不能支持全系列国产 CPU，就可以忽略它了。
我这个观点和别的公众号的观点截然不同。很多公众号天天在说这个国产 CPU 比那个国产 CPU 好，洋洋洒洒列出一堆技术参数、评测比对结果等等......实际大量甲方内部根本没几个人看得懂。
而且，看得懂的人大多数并没有采购决策权，甚至选型建议都不一定会被决策者认同。
因此，在选择服务器操作系统这种纯后端基础信息化环境时，首先应该脱离“选择哪种国产 CPU ”这个误区。重点观察该操作系统是否已经实现了 CPU 无关化，也就是支持的国产 CPU 种类越齐全，该操作系统就越成熟。
CPU 固然是直接影响系统性能，但相对大多数需要实施国产化转型的信息系统来说，因为 CPU 错误选型导致信息系统性能低下进而影响使用的可能性，其实是相当低的。
所以，对于预算有限的甲方来说，抛开“选什么 CPU” 这个桎梏，选择的自由度大了，上下车就更容易，资源不足的窘境才能有所缓解。
信息泛指和操作系统相关的任何信息。信息详尽度很大程度上决定了是否能围绕操作系统建立起自己的良性生态，而生态越蓬勃，预算有限的甲方的在实施国产化替代过程中的选择空间就越大，预算的利用率就越高。
信息详尽度可以区分为以下3个方面：
1、文档手册。如今软件产品的文档手册就是厂商自己在网站上提供的各类参考信息。典型如 learn.microsoft.com 或者 access.redhat.com。
把文档手册放在第一位，是因为在笔者看来，这是操作系统厂商对自己产品的重视程度和投入程度的真实表现。
完善的文档手册需要大量的人力投入，且一般无法和营收直接挂钩。
如果厂商舍得花重本做好文档手册这种基础而又重要的产品信息，简单说就是这个厂家靠谱。
2、垂直社区。比如独立的论坛，或者综合性论坛内的独立讨论板块，以及这些社区的活跃程度。
3、专题内容。比如在独立的微信公众号、独立的博客等 UGC 领域产生的关于该操作系统的内容。
后面这两点是相似的，区别通常在于信息的质量。
操作系统是否具备垂直社区，是操作系统是否具备生态的直接体现。生态中最活跃的因素是人，人因有共同的主题而聚集形成社区，在观点和意见的碰撞中促进生态的形成。
就比如某操作系统A的讨论板块每天1万个贴，而某操作系统B的讨论板块每天只有10个贴，那么即使这1万个贴都是吐槽，也很明显操作系统A具备了生态（雏形）。
信息越丰富越详尽，对于甲方在使用操作系统后的运维过程会有巨大帮助，尤其是资源有限的甲方，往往请不起、请不齐专业运维服务而需要自己运维，那就需要有丰富的信息资源才能支撑。
这一点非常简单，观察操作系统是否具备可相互替代的上游或下游的社区版本。
存在社区版本，是证明操作系统厂商能充分实现开放源码且对社区友好（比如提供充分的软件构建信息）的关键特征。
（写到这里不禁想起 REDHAT RHEL、ORACLE OEL 以及 CentOS 这十几二十年来的纠缠关系）
如果存在上游社区版本，说明采用该操作系统的资源消耗程度是可伸缩的，稍有资源（这里主要指技术能力）的甲方可以通过社区版本配合实现降低信息系统的整体资源消耗。
如果存在下游社区版本，那就能更进一步地说明该操作系统的可替代性。缺乏资源的甲方可直接采用下游社区版本，最大化资源利用率实现信息系统建设。
如果某个操作系统，有上游社区版本但功能差距很大；又或者有下游社区版本但软件包不能通用，这就说明其开放性是存在不足的。资源有限的甲方就应慎重选择，不然上去了下不来，最后倒霉的不仅是甲方单位，还有咱们这些甲方信息化人员。
软件供应链指的是作为甲方要建设的信息系统，所依赖的全部软件组件，实际也包括了操作系统本身。
重点是操作系统是供应链的第一个节点，其它组件需要基于所选的操作系统支撑甲方信息系统的建设和运行。
我把这一点放到最后而不是像别的一些观点文章那样列到第一位，是因为这并不是资源有限的甲方能充分考虑的事情，是乙方要充分考虑的事情。
从专业角度进行的软件供应链成熟度评估，门槛太高了，甲方一般都难以做到，资源有限就更不可能。
要简单地判断操作系统之外的信息系统供应链的其它组件是否适合选择，比如按作者本篇内容，看看这些组件是否也具备相似的情况。另外就是按甲方自己的资源和能力，扩大范围，增加可支撑自己判断的要素。比如把供应链组件继续往前延伸到开发语言一级去评估。
一般来说，常规信息系统所需要用到的组件，除了操作系统之外，重点就是数据库系统了。数据库系统如果同样具备本篇内容所举的几个要点，那这数据库系统大概率就是能延续的。
信息系统的建设成功需要甲乙双方的共同努力，压实乙方责任是其中关键措施。资源有限的甲方更需要向乙方明确责任关系：如果乙方设计的供应链全套组件实际并不成熟，那么栽的首先还是乙方自己。虽然有可能连带地把甲方也带进坑，但在当前环境下，不理性的乙方不可能活下去。
本站微信订阅号：
本页网址二维码：