在了解了目标跟踪扩展策略（Target Tracking Scaling Policy）的机制之后，突然就对 AWS Auto Scaling 有了新的理解。它最核心的部分其实是 CloudWatch！

想明白了这一点之后，AWS Auto Scaling 就不再那么神奇与神秘了。我甚至可以利用 CloudWatch 和 EC2 的相关 API 自己来实现一套 Auto Scaling！

（当然，这并不能否认 AWS Auto Scaling 的强大，无论是在细节上还是用户体验上它都打磨的非常完美了。）

背景

AWS Auto Scaling 有手动扩展（Manual Scaling）、计划的扩展（Scheduled Scaling）及动态扩展（Dynamic Scaling）三种扩展方式。
手动扩展（Manual Scaling）、计划的扩展（Scheduled Scaling）两种方式使用比较简单，本文主要记录我在使用动态扩展（Dynamic Scaling）时遇到的一些疑惑及解答。

动态扩展（Dynamic Scaling）目前支持的扩展策略类型有：

1. 目标跟踪扩展策略（Target tracking scaling）
2. 步进扩展策略（Step scaling）
3. 简单扩展策略（Simple scaling）

详细的介绍可以看官网文档：适用于 Amazon EC2 Auto Scaling 的动态扩展

以下内容会记录一些在文档中没有写清，我通过实际测试并与AWS 技术支持沟通得到的结果。

背景

近期在工作中大量用到了 AWS Auto Scaling，经过多次试验，学习文档并与AWS的技术支持沟通，在我对 Auto Scaling 各项功能不断了解的同时，也深感 AWS 的强大。遇到的种种场景、需求，AWS 似乎早就已经替你考虑好了。
今天我遇到的问题是，在对线上服务器进行变更发版等操作时，要求不能发生自动扩缩容，否则可能导致意外的错误（扩容时，新机器使用的是老镜像。缩减时，发版操作将会中断）。要实现这一点，我想到了很多方案。

背景

通过之前的踩坑与学习，目前我对 AWS Auto Scaling 已经有了一定程度的了解。那么对完成工作需求也就有了更高的标准。
新的问题是：随着业务功能的更新，如何保证 Auto Scaling 可以扩容出与线上保持版本一致的 EC2 实例？
这就要求我们，在业务更新发版后，及时的去更新 Auto Scaling 所配置的映像（Image）。

最近工作不太顺，总踩坑，当然这是客观原因。主观因素呢，就归结于自己经验不足。

这又刚被 AWS Auto Scaling 给坑了，于是学习总结了一番，记录下来，主要是关于 Auto Scaling 的详细介绍和容易犯错踩坑的地方。方便以后自己查询，也希望能帮到看到这篇文章的人。

背景

最近工作中遇到的一个场景：业务系统在国内及国外各部署一套，两套系统有各自的域名。当其中一套发生故障时，要求通过修改域名解析，转移流量到另一套系统进行容灾。
现状是通过脚本进行监控，产生告警后手动修改域名解析实现故障转移，待故障系统恢复后，再将域名解析修改回来。
这样的方式存在的几个明显的问题：

1. 出现故障时，人员响应不够及时。
2. 存在多个业务系统，手工操作工作量大，速度慢。
3. 手工操作易出现错误。
4. 故障恢复后，需要再次人工干预改回解析记录。

为解决如上问题，近几天搭建了一套测试环境，通过 AWS CloudWatch 自定义监控 + Route53 Failover 记录实现了故障发生时的自动切换解析，故障恢复后，自动切回解析的效果。

对 Zabbix 的了解一直停留在听说过没用过的状态，以前通过 python-zabbix 调用过简单的 API，但是讲原理的话我真的说不上来什么。很开心新的工作对我提出了新的要求，我的 Mentor——Rick 也是个很好的老师，从基本原理和架构上给我介绍了 Zabbix 到底是什么。下面是我的学习整理。

近期在工作中有一个需求，按创建年份统计资产的数量，一行代码就能实现，分分钟的事情。后来需求变动，要求按月份统计。我一想，这也没问题啊，对 Django 来说也就是加一个参数的事。代码改完，一调接口，咦，统计结果为什么全是 0 啊？
后面一步一步的定位问题，还挺有意思的，记录下来。

这两天回顾 Python 知识点，想到 Python 中的装饰器和 Java 的注解在语法上如此相像，它们是否有什么渊源？又为什么选用了@符号呢？在 PEP 318 中我找到了答案，在此翻译记录。

使用 Django 的时间也不短了，这两天发现了一个之前没有注意到的有关 Django Model 继承方面的细节。Django 的官方文档中有很详细的解释，查阅之后，在此记录分享。