近期，我参加了微软某部门的知识平台整合工作，正好把微软内部的各个知识管理平台的特点做一个整理，供大家参考。
众所周知，知识管理服务平台其实对任何一家稍有规模的企业都是相当重要的，俗话说铁打的营盘流水的兵，在当今社会，除了在国企，任何一个人都不太可能在一家公司工作一辈子，对公司来说也是如此，你也不能指望员工能在公司里工作一辈子，很多时候因为业务调整、裁员等，人员变动变成了家常便饭。如何将员工在工作中积累的知识财富进行总结和沉淀，如何让新老员工进行知识衔接、新人能够很快地上手工作，如何避免技术骨干将技术和业务带走，都是每一个老板需要经常思考的问题。
微软在这方面也正在进行长期的试验和探索。我在上一篇文章《聊聊微软的大数据平台和一些个人看法》中说过，微软内部是一个基本上完全平等和开放的协作系统，不同的部门、员工间，虽然身处世界各地、时差不同，但是通过工作平台有着无缝和高效的工作体验。围绕着大数据平台，海量文件的相互引用，基本上是一个网状的去中心化的工作环境。因此，他们的知识也是极度碎片化的分配到了每一个工作小组（估计在微软，一、二十人的工作小组达到了上万个）。在此之前每个小组都有自己的知识管理工具和管理方式，甚至每个小组的组员都在同时使用好几种知识管理工具，这样造成了知识的散乱及不易整理，微软自己也意识到了这个问题。因此，从去年起，微软搭建了一个叫Engineering hub的知识平台（eng.ms），并且提供了一系列的工具软件，方便大家将各自的知识管理库迁移到Engineering hub平台上。
在微软，不管什么知识管理平台统称为Wiki，也就是大家所熟知的维基百科。就像百度贴吧一样，Wiki是人人参与，人人贡献力量；每个人既是知识的提供者，也是知识的消费者，这充分体现了微软平等开放的企业氛围；除了Microsoft Confidence的内容外，核心技术绝对不会掌握在某一两个人手上，因此，大家在微软，每天、每时都能够学习到新的知识，如果没有较强的学习能力，是很难在微软长久地工作下去的。
大家平时使用的Wiki，有Sharepoint, Teams, OneNote, DevOps等。
SharePoint微软推出SharePoint已经有了20多年的历史，曾经是最赚钱的软件产品之一，它为企业打造了一个统一的门户平台和业务解决方案，将用户、团队和知识进行整合。进行SharePoint开发需要一定的专业知识，软件本身也拥有相当的复杂性。在微软内部，SharePoint也得到了最大范围的应用，并且与其他软件诸如Teams等进行了深度整合，使得其生命周期在不断地延长。在SharePoint上，文档管理和其他公司的业务知识等进行整合，具有非常大的优势。一般每个团队在SharePoint上都有自己的门户和团队文档，是大家进行学习的好地方。
SharePoint作为微软老牌的产品，其文档管理功能一直没有进行演化，还是采取类似VS Source Safe的独占签入、签出方式，这样一旦有人将文档签出，忘了签入进去，别人看到只能干瞪眼，无法对文档进行进一步修改。相对于云时代多人协同在线进行文档编辑，这样的管理方式显然是落伍了。因此，将类似于源代码管理方式的SharePiont文档管理平台进行迁移，也是很多团队正在思考和在做的事情。
OneNote其实是一个碎片化的知识记录工具，类似于便签，大家把工作中的心得可以随时记录下来，供大家参考，软件本身也在标签上使用了各种颜色予以区分。OneNote结合OneDrive，可以使得文档在各个设备终端上使用。OneNote在记录一些流程、技巧方面有一些优势，但是小组内员工的个人色彩比较浓厚。经过一段时间沉淀，会发现很多当初别人记录的内容已经过时，照着步骤去做全是坑，不如不看，小组内也不太会有人去对几年前别人写的心得做整理和修正，软件本身编目的功能也比较差，系统性、完整性欠缺，所以我感觉OneNote个人作为知识记录工具还可以，用于大的团队就不是很适合了。
微软的Teams是个非常不错的工作协同软件，大家可以把它想象成企业微信，主要用于聊天和视频会议。微软的员工遍布于世界各地，所以选择合适的工作协同工具是非常重要的，相信在微软内部外部工作的同学，上班时间Teams和Outlook是得一直开着并盯着看的。Teams也应该不负众望，很好的担当起工作协同软件的角色。在Teams里，大家可以为工作小组开设Wiki，支持一些有限样式的富文本管理。我想微软也是在做尝试，把Wiki同聊天软件捆绑在一起。可惜的是，Teams的Wiki不支持多级目录的管理，只能记录一些少部分的内容，并且仅限于小组内部的成员观看和编辑，这样就没法把知识分享出去；如果需要让别人能访问到自己的Wiki，还需要管理员进行授权，加到讨论组里面去，所以他的功能就相对比较封闭了；从迁移的情况来看，Teams里面的Wiki是被迁移得最多的，知识相当地分散和零碎，应该说不是个很好的知识管理系统，用于记录小组内的备忘还不错。
应该说DevOps的初衷不是用来做知识管理，他对于敏捷开发的支持、CI/CD集成方面非常完美，也是国内很多开发团队首选的源码管理工具。我们在初始化代码库的时候，可以使用它的Wiki功能，这样就默认生成了以Markdown（.md）格式的Wiki代码库；在文本中使用markdown标签，多人提交PR对Wiki进行管理。DevOps里的Wiki功能已经比较全了，Markdown本身对Wiki的支持就很好，它支持多级目录、目录搜索和全文检索，可以查看各个版本，还可发表评论、标识等；并且可以开放给其他组里的同事看，不需要额外的权限授予。所以微软的一些大数据平台包括Cosmos在内就使用DevOps中包含的Wiki功能；微软在做最后的EngHub整合的时候，也借鉴了DevOps的部分管理功能。
最后请出的是我们的王牌知识管理工具EngHub了，EngHub借鉴了GitHub的思想，是一个工程师（engineer）或者工程（engineering）的平台。微软为此申请了独立的专有域名，有专门的工作小组对其开发和维护。在这个平台上几乎整合了微软所有的业务条线的知识内容，有着海量的目录\分类和内容，对于在微软正在工作\工作过的员工，或多或少都会在EngHub上留下痕迹。
面对一个如此庞杂的的知识服务平台，仅依靠一两个团队是很难将他维护好的。因此，每个团队要将自己的知识贡献出来之前，就要先联系EngHub团队，申请相应的目录和密钥；在记录下代码库地址后，EngHub会以轮询的方式通过版本管理从你的代码库读入文档并转换、整合到Enghub里；他在很大程度上利用了现有的DevOps资源，将内容管理分散到每个具体的团队，又能够进行高度的统一和整合，其统筹的思路很值得我们的管理者进行借鉴。
EngHub背后的文档解析使用的是Docfx引擎（https://github.com/dotnet/docfx），微软使用的还是内部的一个专用的分支版本，目前稳定版本是2.x； 3.x都是Beta版本，和2.x有些兼容性差别，不太建议使用。EngHub网站前端使用的展现引擎竟然是nodejs技术栈的react?!，具有一些无刷新SPA的体验，希望有一天能用上Blazor 。
我当时为了把团队各方面零散的重要的知识整合到EngHub里，前前后后零零散散忙了半年，迁移了数万篇文档，几个G的内容，这些内容在EngHub上的目录结构里仅仅是一个很里层的很小的一个链接。因此可叹EngHub规模的庞大，有时间的话逛逛EngHub也是很有趣味的，前提是你要对计算机有兴趣，并且英文还算过得去。
“一直在模仿，从未被超越”对于微软来说是最恰当不过的。在技术上从来不进行头部创新，而是采取跟随者的策略，自己的企业反而在市场上始终处于领先位置，是商战里常用的一种策略，国内的企业我就不举例了。拿微软说，它的Windows图形界面抄袭MacOS，IE浏览器抄袭Netscape，后来IE、Edge纷纷被Chrome超越，又反过来用Chrome的引擎做Edge。微软内部的大数据引擎Cosmos应该是Hadoop的一个发行版本修改而来的，至今也没有开源，它运行在windows平台上，增加了对.net的支持，定制了一些功能，加强了稳定性。在Cosmos上可以使用Java、Scala、Python等语言进行开发，也可以运行Spark、YARN等作业，这不就是Hadoop套个壳么.......
在微软，使用各种语言开发的人很多，代码中使用设计模式的很少，倒是使用模板语言、DSL的比较多，比如Cosmos上运行SCOPE、为ObjectStore做定义的Bond等，都是一些模板语言+语法糖。
使用大数据平台，少不得在各个系统间相互调用，一般用的都是Azure Function、WebHook、WebAPI等。Http本身就不是可靠的的通讯协议，所以在相互调用中，会经常出现404、500错误，一般要设立重试机制。从.net core开始，微软就不再提供WCF，旧项目迁移到.net core\5\6需要第三方WCF库，协议和功能方面有着很多限制；我发现微软对SOA的热度正在冷淡，重心逐渐向微服务、容器化、SAAS、PASSS、低代码平台上转移。因为如果使用WCF、WS等SOA等技术，大数据平台及和周边的应用之间的通讯质量还是可以得到保证的。在微软，我还没碰到比较好的架构师，只是大家对如何协同工作以及程序健壮、稳定性方面有着一定的共识，代码写得特别烂的人也进不了微软周边；微软地很多产品我想都是对开源产品的模仿，也就是我们俗称的重复造轮子，然后在上面构建自己的业务系统。
微软外服工作札记系列
①聊聊我在微软外服大数据分析部门的工作经历及一些个人见解
②聊聊微软的知识管理服务平台和一些编程风格
③窗口函数的介绍