技术尽职调查清单

引言

本文实际上是关于两件事。首先，它主要关注于在将新技术系统引入组织时进行尽职调查的清单，其次，我也发现它在我进入一个新角色/工作，需要负责一个现有的遗留系统时非常有用。浏览这份清单可以让我更深入地了解我个人将要面对的情况（如果我承担所有权），或者组织将要面对的情况（如果你只是提供建议）。

关于组织的技术需求，一个标准的“大问题”是他们是“购买、构建还是授权”所需的解决方案。这些选项各有优缺点，取决于组织、他们的需求以及现有可用的选项。无论最终选择哪种方式，通常都会有一个评估流程来确定最适合组织需求的解决方案。随着越来越接近做出决定，尤其是对于大笔支出，评估将超越表面上的“试驾”，进入一个真正的尽职调查过程。多年来，我曾参与过公司和技术收购及授权过程的双方，其中大部分都与技术尽职调查过程有关。最近我再次提到过它，所以我想分享一下我期望涵盖的清单。一如既往，这些项目基于我的经验，你的可能有所不同。分享知识并不断改进是件好事，所以如果你看到了遗漏但值得添加的内容，请在下方留言！

背景

当一家公司在某项技术上花费巨资时，无论是固定期限的授权解决方案，还是作为公司收购的一部分，通常都需要评估技术本身以及开发、生产和维护流程。这是为了确保它符合预期用途，并有望满足采购组织的需要。这不应该是一个对抗性的过程，而是一个积极的互动过程，旨在确保交易双方都清楚销售的是什么以及购买的是什么。当公司创始人就产品和服务责任向采购组织做出个人承诺时，这一点尤为重要。

我已经将清单分解成几个不同的部分，从需要从技术层面进行检查的高级法律事项，到低级代码调查，再到生产、维护、可扩展性和支持。

左键单击 gadget 并拖动以移动它。左键单击 gadget 的右下角并拖动以调整其大小。右键单击 gadget 以访问其属性。

许多事情可以归入“通用”类别。通常，我将此视为一个“热身”环节，从宏观上了解事物，然后再从微观上进行深入研究。这有助于提供一个良好的视角，并为你深入挖掘时提出问题奠定基础。

• 架构概览
  一种有用的方法是使用“4+1 架构视图模型”来审视架构。该模型由Philippe Kruchten设计，从不同角度全面看待整个系统及其各个方面。
  
            “四个”...
  • 开发 - 这是程序员的实现视图，展示了事物的组合方式。
  • 逻辑 - 概述了向最终用户呈现的功能。
  • 物理 - 系统的工程/物理基础设施视图。
  • 过程 - 指运行时实现、通信、可扩展性、并发性。
    
    “加一”
     
  • 场景 - 一系列用例，描述了系统的不同用法，使其他四个视图更具可比性。
• 供应商平台特定要求
  这指的是系统运行平台选择带来的任何要求。如果是移动端，是否需要 Mac 开发工具？如果是基于云的，是否特定于 Azure、AWS 或 Google？它是否使用了该供应商的基础设施？
   
• 端到端工作流程
  在这里，我们记录了系统的总体端到端工作流程（当然，这取决于系统的复杂性）。这里与架构概述的过程视图存在重叠，但在这种情况下，它会更深入。试图清晰了解的一个关键点是任何涉及手动干预的流程，反之亦然，流程自动化的区域。

代码/数据质量

这是我们深入研究系统核心问题的地方。我们关心系统中的代码/技术的质量是高还是低。对于拥有大量数据资产的系统，我们也应该关注数据本身的质量。糟糕的系统构建会给组织及其工程部门带来沉重的“技术债务”，因此特别注意这个领域非常重要。如果持续维护和未来开发的成本因代码或数据资产质量低下而受阻，则需要在收购过程中在财务和运营上将其考虑在内。

• 代码覆盖率
  虽然并非每个人都认同这个指标，但它至少是我们可以查看的一个衡量标准，而衡量对于理解系统并评估其当前状态和未来维护考虑至关重要。如果系统存在少量或质量差的测试，您就需要质疑系统的健壮性。
   
• 代码质量/优化
  拥有单元测试固然好，但如果代码本身不是最优的，也会导致长期问题。在这个类别中，我们不是在寻找节省毫秒的处理时间，而是寻找合理的编码实践，并留意糟糕的流程和调用。
   
• 文档
  作为开发人员，我们有多少次接手了他人的工作，甚至查看了自己几个月或几年前的工作，然后感到困惑——这是怎么回事？…这就是文档的职责。查找行内代码注释、整体开发参考文档、关于整体物理/服务架构设置和维护的说明、与数据（输入和输出）相关的特定说明、提供的和使用的 API，最后是最终用户文档。
   
• 测试
  标准单元测试当然是预期的，但不仅仅是后端。如果这是一个多层系统，也请查看前端和数据存储库的测试流程。有些地方很难测试，比如 UI，所以要看看这里使用了什么方法，以及如何处理回归测试。
   
• 缺陷管理
  深入了解系统中历史和已开放的缺陷，不仅可以让我们了解系统的健壮性，还可以了解问题通常发生在何处、问题的严重程度，以及是否存在对问题类型的总体识别和随时间的总体改进。
   
• 错误报告
  等待客户报告现场环境问题是一场危险的游戏。最佳实践是拥有一个内部系统错误日志记录系统，以及对遇到的错误进行持续监控和报告。检查代码中如何处理错误，以及管理日志的机制是什么。
   
• 安全
  如今，我很难想到有哪个系统不是以某种方式连接到更广泛的互联网的。我通常建议客户不要考虑“如果”他们的系统被黑客攻击会发生什么，而是考虑“何时”会发生。根据系统的类型，安全性可能重要或不那么重要。例如，在医疗和金融领域，数据可能比其他领域更敏感。任何对系统安全性进行调查都应检查系统及其数据在运行中、传输中和静止状态下的情况。应特别注意任何直接暴露给外界的区域。

可扩展性

很少有技术会被仅仅因为其当前状态而被采纳，通常收购方希望获得投资回报，并希望利用其收购的技术来扩展其服务。因此，在尽职调查过程中，我们通常需要关注技术的扩展性，这如何运作，以及在增长过程中可能遇到的任何问题。在这个领域，我们可以从几个方面来指导这个过程。

• 操作系统平台
  根据技术，我们需要检查操作系统平台是什么以及它如何扩展。即使我们说，哦，没关系，它是移动端的，我们只需要担心设备性能，那么后端呢？…它需要扩展吗？如果服务是基于云的，它是使用 Azure 上的 DocumentDB 或 AWS 上的 Elastic Beanstalk 等托管服务构建的吗？它是否依赖于需要仔细监控、协调和手动维护和打补丁的一系列 DevOps 管理的虚拟机？
   
• 可扩展性
  在这里，我们需要检查系统，看看它是否考虑了未来的增长。是否存在任何明显的增长障碍？例如，如果客户数量在早晨翻倍，这会导致什么问题？…需要多长时间才能（技术上）让新客户入驻？是否存在为客户进行的任何非自动化的入驻流程？
   
• 灾难恢复
  无论我们如何周密计划，意外总会发生。当这种情况发生时，从尽职调查的角度来看，我们想知道如何恢复技术或系统。有哪些计划？需要采取哪些步骤来完全重建系统？紧急更换部署/生产平台或云提供商呢？如果发生重大数据丢失，关键的备份和关键数据/服务/配置存储方法是什么？
   
• 诊断监控
  我不断告诉人们的一件事是，“我们不知道的东西也很重要”。太多的人捕获和记录错误，但我们多久查看和检查这些日志以了解我们可以学习和改进什么？在这里，我正在寻找任何有关日志记录和对生成的日志进行分析以提高系统质量和性能的流程。
   
• 瓶颈
  一个系统没有瓶颈是很罕见的。不可避免地，有些东西会悄然而至，没有被充分考虑，或者从未打算长期保留在生产环境中，或者是一个变成了重要功能的临时解决方案。这些瓶颈可能是扩展的致命弱点。特别关注外部世界与系统接触的区域。客户是如何入驻的？是否定期导入外部数据？如果是，是否自动化？设置如何？这些系统有哪些监控？如果数据未能传入，或者传入过多，系统是否会因此受到数据量的限制？（等等！）
   
• 网络图
  虽然严格来说属于架构的一部分，但我喜欢深入研究网络和通信的构建方式，特别是任何可能导致在情况迅速升温时减慢速度的区域。
   
• 未来计划
  了解我们今天拥有什么是一回事，但系统未来的计划是什么？…这些新计划的实施将如何影响现有系统？任何区域是否需要因此进行返工/修订？
   
• 数据存储库
  假设系统处理数据，这些数据是如何存储和管理的？当前数据量是多少？数据存储限制是多少？当前每天/每月的数据增长率是多少？存储库如何处理 10 倍、100 倍的增长？使用了什么类型的索引方案？数据是否经过预处理和反规范化以实现快速查找（如果需要）？是否使用了内存数据库？唯一标识符/主键是如何生成的？这是否会导致快速移动的数据出现问题？
• 负载测试
  系统是否经过压力负载测试？如果是，使用了什么方法，是否可以复制？如果不是，扩展测试需要什么？能否做到？负载测试可以快速识别扩展问题，值得认真考虑。

生产

一旦你检查了系统的核心组成部分，你就需要检查它在生产环境中的实际运行情况。运行系统指标如何？系统是否处于压力之下？它是否得到了充分利用？是否存在 IO 或网络带宽问题？仔细检查系统在实时生产环境中的运行情况非常重要——有时人们认为正在发生的事情并非如此，例如在进行维护操作时运行一些性能监视器可以提供有价值的见解。

• 部署
  代码完成后，如何将其推送到生产环境？检查是否使用了持续集成和部署，进行一些小的更改或测试以观察其运行情况。如果你需要创建一个全新的系统实例或将其迁移到另一个提供商，该如何操作？确认所需的步骤。
   
• 第三方依赖
  在生产环境中，识别并记录任何第三方依赖项非常重要。不仅要了解使用了什么以及如何使用，还要了解其任何许可要求。此外，您还需要检查任何第三方项目是否存在扩展性和支持与维护方面的潜在问题。
   
• 基础设施健康监控
  我们知道需要在代码层面检查错误捕获、日志记录和报告，但同样重要的是在系统生产层面相关的操作。询问进行了哪些 OS/VM/Container/Infrastructure 健康监控，日志的检查频率，以及对更严重的日志项进行了哪些类型的自动化报告。
   
• 数据归档/清理寿命
  确定了哪些流程用于数据归档，以及在必要时进行数据清理。检查归档是否需要将任何系统移至离线状态，或者是否可以实时进行？此外，确认数据和整个系统的恢复测试程序，并查找相关的日志以进行确认。
   

支持

很少有系统能够独立运行而没有问题，在本节中，我们检查了为开发、维护和最终用户支持而设立的结构。

• 现有开发支持
  当新的开发资源加入团队时，是否有正式的技术入职流程？如果有，请调查其内容。是否有与第三方供应商或服务商签订的协助开发团队的合同？如果有，请审阅这些合同并评估条款、条件和成本。
   
• 最终用户支持
  除非您评估的系统仅仅面向技术，否则您将面临某种程度的最终用户支持需求。人们期望您正在评估的技术的开发商拥有自己的支持系统，例如客户问题数据库、错误、常见问题解答等。查看用户支持历史记录可以极大地帮助评估您组织内部未来的支持需求，以及这些需求可能如何（或不可能！）扩展、涉及的成本等。用户支持通常遵循一个曲线，在用户开始使用某个系统时需要更多的指导，在引入新功能时也是如此，但之后会趋于平稳。重要的是要了解用户支持如何融入整体图景，因为繁重 Thus user support can kill or dramatically slow down an integration project.

法律

尽职调查的法律要求可以分为两部分。一方面是宏观的法律层面，涉及合同、财务等；另一方面，从技术尽职调查的角度来看，我们更关心技术本身的法律方面；谁拥有它，是否存在第三方许可，使用是否有任何限制等。

• 代码所有权
  表面上看，代码所有权并不像人们想象的那么简单。互联网提供了代码的开放存储库，我们可以复制粘贴，而这些代码可能附带某些条件，也可能不附带。有些开源代码允许完全商业使用，有些则限制用于非商业用途或其他开源项目，当然还有介于两者之间的各种选项。在opensource.org 上有一个有用的开源许可证列表。在这里要检查的重要事项是代码的来源，是否是按许可使用的，如果是，谁拥有该许可证，并且其使用是否被允许。
   
• 许可证侵权
  谨慎的做法是特别要求并检查任何针对第三方许可侵权的赔偿保险。您希望尽可能确保您不转移或传播错误发生的责任，或者如果您这样做，您也希望减轻风险。
   
• 合规与监管
  根据您运营的国家和行业，您的技术可能需要遵守某些合规性或监管法律或规则。这可能包括与数据相关的隐私法，以及医疗和航空技术领域的标准和质量法规。与业务和业务法律团队沟通，了解在技术层面是否有任何需要解决的问题。
   
• 定期许可
  许多产品使用每年更新的第三方许可证。有时它们是为某个目的购买的，但从未使用过，有时它们带有每年都需要持续使用的经常性许可费。无论存在哪种类型的许可，都需要识别、检查和验证任何第三方许可，以确定是否存在任何持续性责任。
   
• 许可转让
  某些形式的技术许可明确禁止许可转让。这是出于各种原因，其结果通常是需要签订新的许可协议，通常会产生相关费用。大多数合同都包含关于所有权和所有权转让的条款。如果不清楚，请移交给法律部门澄清。

适用性

这个类别是一个动态目标，取决于技术本身、它在组织中的定位以及组织所在的行业等。归根结底，您想知道您正在采用的技术解决方案是否适用于您的组织打算使用的目的，以及最终，它是否是一个好的匹配。

• 差距分析
  创建一个表格，列出您的组织对您希望引入的技术的期望。将每个期望评为“必须拥有”、“必须能够拥有”和“最好拥有”。“必须拥有”的项目通常是决定性的障碍，“能够拥有”是可以轻松添加的功能，“最好拥有”是额外的好处。不要陷入将所有内容都视为“必须拥有”的陷阱，实际上很难找到完美的匹配，您应该期望在收购新技术后进行一些更改。一旦您有了列表，就可以简单地随进度检查各项，并很快就能看出是否匹配（无论其他方面如何影响您的总体评估）。
   
• 技术匹配
  除非您同时收购了开发团队和技术，否则在确保技术匹配方面要非常谨慎。您不希望批准一个使用 Java 或 Python 框架编写的系统，而您的内部团队却精通 .net 世界（反之亦然），而不为此类维护和开发资源、培训等做出适当的建议。
   
• 技能匹配/差距
  除了查看基础技术使用上的匹配和差距外，还要考虑任何技能上的匹配或差距。例如，您的内部团队可能在 MS SQL 方面有经验，但正在接收的技术是基于 NoSQL MongoDB 和 Redis 集群的。
   

总结

重申一下，此清单基于个人经验，不一定适合所有人。此外，我敢肯定还有其他人会分享宝贵的经验——请留言，以便我们能使其成为一个更好的资源！

 

历史

2017年4月22日 - 版本1