最近团队里有同事在做把本地产品迁移到SaaS的评估工作，他整理了一些需要评估的内容，我觉得还挺不错的，自己在他基础之上根据自己的经验做了一些增删，在这里作一篇笔记。这里面的内容其实也适用于购买一个新的SaaS服务的checklist。

主要分为服务可用性，SaaS和本地部署的功能对比，性能，安全，运维，数据迁移，与公司其他应用的集成 这几个方面。

服务可用性

python的多任务其实用了很久了，因为刚开始写代码的时候总是看网上说高并发、异步之类的，就觉得很高大上，所以刻意地去学过，后来在实际开发工作有过为了使用而使用，也有过真正因为性能问题而必须要使用。今天想把目前掌握的一些内容记录下来。

其实应该介绍一下网上流传甚广的“Python速度慢”和GIL，但是这两个话题在网上有非常多的文章讨论过，就不想再多写了。

Python多任务其实有多线程、多进程和协程三种实现方法，但是协程一般只在性能要求特别高的情况下使用，并且在实现上相对于多线程和多进程要复杂一些，所以不在这里写，以后单独为协程写一篇笔记。

最近在公司做一个项目，跟以往不同的是，在这个项目中，我有点类似于项目经理的角色（但我并不是项目经理）。换了一个角色，发现要想成功做成一个项目，远不是光有好的技术就可以的。

记录一下最近的感受，主要分为这几个方面：充分沟通、预期管理、协调同事关系、任务分配、超前规划。

下面对每一项单独记录。

去年开始写年终总结，今年照例也写一份

工作和技术学习

先说说工作相关的。

之所以想要写这篇笔记是因为上周我们的监控系统发生了一件我以前遇到的事情，这次虽然没有造成严重后果，但是很值得反思。

先说说发生的事情，也就是背景。

我们的监控是基于Prometheus构建的，然后利用grafana做可视化，都是部署在k8s里面的，这个k8s同时也是业务所在的集群，这应该也是很普遍的做法，而且网上很多教程和博客都是这么写的。

所谓“延迟”其实就是指响应时间，比如一个web页面的响应时间，一个api接口的响应时间等等。

这篇笔记分如何实施和如何使用两部分来讲关于延迟的监控。

笔记中不会写实施的详细的步骤，因为这样的内容网上非常多，更多的是记录在使用中一点感想和建议，如果读者正好也在做类似的事情，可能会在思路上能够提供一点点的帮助

我与监控的缘分

可能真的是与监控这个事情挺有缘分的，从第一份工作的第一个项目开始，就跟监控有关系。
一开始是做ELK，用于数据收集和分析的，后来就利用各种beat和logstash的一些能力尝试做系统监控；后来又配合过另外一位同事基于Zabbix改造公司的监控系统，再后来简单的做过基于Promethues对k8s进行监控；最近一段时间又开始带着构建部门的监控系统，回头一看，发现我工作四年多一点，竟然一共做了4次跟监控相关的事情。
但是每一次做的形式和收获都有一点不太一样。

监控的目的

前面一篇笔记写了一点关于构建监控系统的想法，今天详细记录一下里面提到的关于系统“可用性”的监控。

系统可用性监控主要有三种实施方法： 1. 通过对日志解析和分析做 2. 通过外部黑盒系统做 3. 在开发的阶段就开发相应的功能。下面一个一个具体说一下。

通过日志做可用性监控

写在前面
以下提到的代码的代码仓库：https://github.com/yexia553/drf
分支： others

认证和权限

在实际开发中，认证这一部分常常是使用jwt，但jwt是相对独立并且比较复杂的模块，这里就不过多记录，以后有机会专门写一下jwt和drf的配合使用。

在Django rest Framework入门 二 ：DRF框架初体验中其实已经使用了视图了（book.views里面的代码），而且就是实际开发中最常用的模式，但是那是经过DRF框架高度封装的，代码的可读性不好，而且如果不了解里面的细节，当以后遇到需要定制化的工作时可能就无从下手，这一篇笔记会记录一些我自己认为比较重要切常用的实现细节。

写在前面：
本文后面所有的代码样例中，book.urls里面，以下两段代码只能二选一，使用其中一个的时候必须把另外一个注释掉。

第一段是与ViewSet配置使用的，第二段是与ModelViewSet配置使用的。