购置SaaS产品需要注意的事项

文章目录

效劳可用性





SLA效劳支持





功能对比性能





只要一个办公地点有多个办公地点





安全





数据安全网络安全





运维管理





状态变卦通知监控





数据迁移与公司其他应用的集成





功能是否可用网络可达性

最近团队里有同事在做把本地产品迁移到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产品，测试非常重要，一定要尽量多的同相关利益人沟通，多开掘一些测试场景，这样才干尽量少采坑。
同步发表于个人站点：http://panzhixiang.cn/article/2022/10/4/54.html