潘智祥

发表于 Waline： 本文字数： 1.8k 阅读时长 ≈ 6 分钟
本文详细记录系统“可用性”监控的三种实施方法，包括通过日志解析分析、外部黑盒系统以及在开发阶段就开发相应功能，还阐述了各方法的实施方式、优缺点及相关思考。

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

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

通过日志做可用性监控

发表于 Waline： 本文字数： 2.3k 阅读时长 ≈ 8 分钟
本文介绍了DRF（Django REST framework）的认证、权限、限流、排序和过滤器相关内容。包含认证和权限的配置代码，限流的两种方法，排序和过滤的实现步骤及示例，还给出了代码仓库地址。

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

认证和权限

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

发表于 Waline： 本文字数： 2.1k 阅读时长 ≈ 8 分钟
本文记录Django rest Framework视图实现细节，介绍ModelViewSet和ViewSet的使用。ModelViewSet适用于有对应数据库模型类场景，可高效实现增删查改；ViewSet适用范围更广，文中给出代码示例及url配置。

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

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

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

发表于 Waline： 本文字数： 1.4k 阅读时长 ≈ 5 分钟
本文介绍DRF框架中序列化与反序列化的概念，详细讲解Serializer类（包括ModelSerializer和Serializer）的使用及代码示例，还提及两者的取舍，并介绍了数据校验的方法，代码repo见https://github.com/yexia553/drf 。

笔记中提到的代码repo：https://github.com/yexia553/drf

序列化与反序列化

简单地说，序列化就是从数据库中取出数据处理后传给API（请求方）；反序列化就是从API（请求方）获取数据处理后存到数据库中。

发表于 Waline： 本文字数： 977 阅读时长 ≈ 4 分钟
本文记录了Django rest Framework简单使用体验，包括安装配置、编写序列化器、视图、修改url配置及测试等内容，还给出代码repo，展示了DRF框架如何减少重复代码。

Django rest Framework入门 一 ：手工实现常见API中记录了如何手工基于Django实现常见的API类型，这篇笔记记录一下DRF框架简单使用的体验。

笔记中提到的代码repo：https://github.com/yexia553/drf

安装和配置修改

发表于 Waline： 本文字数： 1.3k 阅读时长 ≈ 5 分钟
本文介绍Django REST Framework，它是基于Django的前后端分离框架，可封装后端功能成API。还讲解手工实现API，包括常见API类型、项目结构及代码解释，以图书信息应用为例，含列表视图和详情视图代码。

Django REST Framework

Django本身是一个前后端不分离的框架，适合很多相对简单的开发需求，但是现在很多场景比较复杂，尤其是前端比较复杂，而现在很多前端框架都很不错，能极大简化前端开发工作，这个时候前后端分离就很有必要了；而且现在一般团队中开发成员也都是前后端分离的，前端专门开发UI，后端专门开发业务逻辑；再加上微服务的流行，后端API化的趋势已经很明显了。
Django REST Framework就是一个基于Django的前后端分离框架，可以将后端的功能封装成API对外提供服务。

手工实现API

发表于 Waline： 本文字数： 109 阅读时长 ≈ 1 分钟

枸杞岛东崖绝壁的日出

这是前年去枸杞岛玩的时候拍的一张日出，这是我第一次在海上看日出，非常震撼。

照片是用iPhone8原相机拍的，没有任何滤镜和后期加工。

发表于 Waline： 本文字数： 1.8k 阅读时长 ≈ 6 分钟
本文指出约70%的故障发生在变更时，强调变更是故障主要来源之一，还分享了使用Jenkins做CICD降低故障率的经验。同时从多方面探讨了Jenkins和Github Action的选型问题，为企业CICD系统选择提供参考。

70%的故障都发生在变更的时候

今天在读《SRE·谷歌运维解密》的时候，有一句话让我感触很深。大致意思如下：一个服务大约70%的故障都发生在变更的时候。

70%这个数字不知道他们怎么得来的，但是从个人作为开发和运维两个角色的经验来看，这句话背后想要表达的观点是正确的：变更是故障的主要来源之一。

发表于 Waline： 本文字数： 287 阅读时长 ≈ 1 分钟
作者分享B站上一个DRF教程，链接为https://www.bilibili.com/video/BV1Sz4y1o7E8 。该UP主是培训机构讲师，教程优点是讲清代码精简过程，助于理解DRF框架；缺点是对DRF和Django具体使用讲解少。感慨B站入门资源丰富。

其实使用DRF也有一段时间了，一些常用的功能基本没有问题，上周在B站上看到一个DRF的教程，看了一下目录觉得还挺齐全的就看了一遍，发现确实很不错，以下是视频的链接：
https://www.bilibili.com/video/BV1Sz4y1o7E8

这个UP主应该一个培训机构的讲师。

说说优缺点。

发表于 Waline： 本文字数： 618 阅读时长 ≈ 2 分钟
本文分享读《SRE·Google运维解密》监控一节的感悟，探讨临时解决办法带来技术债务的问题。结合书中Gmail监控系统案例，分析团队在处理问题时的冲突，强调管理者应重视长期修复工作，技术债务问题值得与上级讨论。

今天读《SRE·Google运维解密》中关于监控一节的时候，有一段内容讲到了workaround
或者说临时解决办法可能会带来难以偿还的技术债务的问题，在我自己的工作经历中确实有
过这样的经历，值得思考。

人其实是有惰性的，一旦在发生的问题的时候通过某种简单的方法绕过了根因通过打补
丁的方式“解决”了这个问题，那么在没有明确的激励机制的情况，很多时候就不会愿
意再花时间和精力去从根本上解决这个问题。

以下是书中原文

0%