购买一个SaaS产品需要注意的事项
最近团队里有同事在做把本地产品迁移到SaaS的评估工作，他整理了一些需要评估的内容，我觉得还挺不错的，自己在他基础之上根据自己的经验做了一些增删，在这里作一篇笔记。这里面的内容其实也适用于购买一个新的SaaS服务的checklist。
主要分为服务可用性，SaaS和本地部署的功能对比，性能，安全，运维，数据迁移，与公司其他应用的集成 这几个方面。
服务可用性
服务可用性分为SLA和服务支持两个小的方面。
SLA
SLA是指一年中服务可以正常使用的时间的比例，一般来说商业SaaS产品的SLA在99.5%~99.9%之间。
在考量这个指标的时候需要考虑两方面的因素，一是公司内部其他使用这个产品的团队的需求，要跟他们沟通这方面的情况；二是公司对外提供的商业产品如果也依赖这个产品就要额外注意，因为这个SaaS产品的宕机也可能导致我们自己的商业产品不可用，进而影响我们对客户的SLA，SLA不达标可是要赔钱的。
服务支持
服务支持指的是当我们遇到问题的时候怎么获取对方公司的支持团队支持。
一般来说有以下几种途径可以获取对方的支持：
- 在专门的support页面提交case
- 邮件
- 专门的沟通软件，如企业微信、钉钉、Slack等等
- 电话
- 视频会议
不同方式的方便程度是不一样的，在评估这这一点的时候除了要注意对方会提供上面哪些类型的支持之外，还要注意两点。一：响应时间，这对于发生宕机和其他重要事故的情况来说是非常重要的；二：不同的响应方式是否单独收费，有一些公司（尤其是国外的公司）对于实时响应是单独收费的，要注意这一点。
功能对比
有时候同一个产品的SaaS版本和自部署版本在一些功能是有差别的，不论是新购买还是从本地迁移都需要注意这些差别，最好可以跟对方SaaS售前和自部署的售前都聊聊，有时候会获得不同的消息。
性能
这里想要讲的性能主要是指网络性能。
根据公司的办公地点分散情况分为两种情况：只有一个办公地点和在全国甚至全球的多个城市都有办公地点。
只有一个办公地点
这种情况下，公司不论是自建机房还是使用公有云，自部署产品的时候，服务距离使用者是比较近的，而且跟公司其他应用的距离也很近（如果是本地机房的话可能就在同一个机房内），所以一般来说网络性能上不太会有问题。
但是如果采购SaaS服务的话，就要特别测试一下网络性能，并且要同时测试普通使用者和有集成关系的系统。
因为SaaS公司出于投入的考虑不太可能在全国（全球）的每个城市都部署服务端，所以可能你的使用地点和SaaS服务器地点相距很远，势必会影响网络性能。
有多个办公地点
如果公司有多个办公地点的话情况就更复杂了。
除了上面只有一个办公地点要考虑的那些事情，一般还有以下情况需要考虑：
CDN
如果办公地点大于3个并且距离很远，很可要就要考虑支持CDN，不然不管怎么选择服务端的地理位置，都很难平衡每个办公的地点的性能要求。不同地点之间的数据转移
最好可以支持网状传输数据而不是星状。所谓网状就是任意两个点之间都可以直接传输数据，星状就是所有只能通过服务器中转消息来沟通。
不过这一点也是根据实际需要决定的，不是所有的场景都需要这个功能。
安全
安全分为数据安全和网络安全。
数据安全
有一些法律法规会对某些行业有一些限制，比如不能托管数据等，所以在采购SaaS服务的时候最好和公司的法务团队沟通好，并且留下沟通的证据，已备将来审计时需要。
即使在没有法律限制的情况下，也一定要详细了解采购合同中关于数据安全的部分，并且要和法务团队仔细研究、核对
网络安全
在自部署的情况下，服务很可能只有内网才能访问，但是SaaS产品往往是对互联网发布的，这就带来了网络安全的隐患。
建议可以从以下几点去考量：
- 是否有WAF，对于暴露在公网上的服务来说这一点至关重要
- 是否支持2FA，也就是双因素认证
- 是否有详细的访问审计功能（谁在从哪里在什么时间做了什么，成功与否）
- 与公司的安全团队共同评估（一方面借助他们的专业能力可以进行更加完善的评估，一方面多找一个团队帮你背书）
除了数据安全和网络安全，另外有一点有关注的就是完善的审计功能，尤其是在上市公司或者跨国公司中要特别注意这一点，因为可能会有法律上的要求。
运维管理
其实理想状态中的SaaS产品应该是0运维的，但是现状是达不到0运维的，一般还需要关注两个方面的运维工作：状态变更通知和监控。
状态变更通知
所谓状态变更通知就是在服务的状态发生变化的时候以有效的方式提前通知到用户，比如在升级、维护、故障的时候。
现在大部分的SaaS产品只支持发送通知给管理员，不能发送给产品的终端用户，需要管理员（一般就是我们自己）中转一下，最好可以把这一部分做成自动化，因为依靠少数几个管理员人工中转通知，如果在某一次重要的节点漏转发的话就有可能导致严重的后果。
监控
任何一个对外提供服务的的系统都应该有配套的监控，否则对于维护的人来说就要一直提心吊胆，不知道什么时候就会有一个”炸弹”丢过来。
有的SaaS产品会为客户提供完善的监控和告警系统，甚至还提供可以二次开发的API，这是比较理想的。
但是也有的SaaS产品没有为客户提供监控系统，如果在这种情况下还是要采购这个产品的话，最好自己针对重要的功能或者场景做一些黑盒监控，否则真的是两眼一抹黑，啥也不知道。
数据迁移
在已经使用了自部署的服务之后要迁移到SaaS端的情况，一定要考虑的数据迁移，如果公司的信息安全政策和法务允许的话，最好可以在采购之前（比如POC的时候）做一次实际的数据迁移工作。“销售的嘴，骗人的鬼”，不要轻信销售和售前的话，真的有问题头疼的是我们。
与公司其他应用的集成
SaaS产品与公司其他应用的集成应该考虑两个方面：功能和网络可达性。
功能是否可用
这一点还是上面提到过的问题，同一个产品的自部署版本和SaaS版本在功能不一定完全一样，所以一定要真正的去做一次集成才知道到底行不行，不要盲目信任对方提供的文档，起码从我目前的经验来看，文档有错漏是很正常的，哪怕对方业界一流的公司。
网络可达性
SaaS产品往往是对公网发布的，而公司的应用很多都是只对内网发布的，所以在通信的时候可能会遇到网络上的问题：网络不可达或者网络性能不达标。这都需要实际的测试才能知道。
总得来说，购买SaaS产品，测试非常重要，一定要尽量多的同相关利益人沟通，多发掘一些测试场景，这样才能尽量少采坑。