背景

按照团队的标准规范，在 AWS 上新建的 EC2 实例都要添加 Name, Region, App, Env, Layer, Group 等标签。其中 Name 标签的格式是：{Region}-{App}-{Layer}-{Env}-{Group}-{IP后两段}，例如：vg-store-web-release-a-12-34。
在 Auto Scaling Group 的配置上，我设置了为新扩容出的实例自动添加 Region, App, Env, Layer, Group 这些标签，但因为 Name 标签中包含 IP 后缀，因此没办法预先设置在 Auto Scaling Group 上，只能在实例创建出来分配到私有 IP 后手动的添加 Name 标签。

为了解决这个问题，我最先想到的方案是：使用脚本调用 API 定时扫描没有 Name 标签的实例，然后获取实例的 PrivateIP 和其他标签拼装出 Name 添加到实例上。
我很快就编写出 Demo，经过测试，可以实现需求，但总觉得不够优雅：

1. 需要定时调用脚本，间隔时间过长就不能及时发现新扩容的实例，间隔过短则显得有些浪费计算资源（事实上，在我们的业务场景中发生扩容的次数很少，间隔以天为单位设置都有些多余）。
2. 需要部署维护脚本及crontab。
3. 需要找一台服务器运行脚本。

后来我想到了 Auto Scaling Group 有 LifeCycle Hook，又从它的设置界面了解到了 CloudWatch Events 这一服务。
最后通过 CloudWatch Events 和 AWS Lambda 就可以很好的实现我的需求！

在了解了目标跟踪扩展策略（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 中我找到了答案，在此翻译记录。