背景 #

2017 年的年末，我在 REA Asia 团队担任 DevOps 工程师的角色。当时刚刚完成一个站点 AWS 端到端的上线，这也是我第一次完整的从零独立设计完成一个 AWS 上 Web 的架构设计以及自动化实现。这也使得我能够亲自实践如何从零设计和实现一个兼具安全和稳定，并且 DevOps 友好的应用架构。于是我十分想把过程中遇到的体会和心得能够记录下来。

偶然在 To China 邮件列表里看到了三周三页面工作坊成功结束的消息。于是我想，何不把我过去所做的内容分解一下，变成四周四架构？

学习的假象和真相 #

2016年，我在武汉 Office 出差，当时因为学习了 Coursera 上的 “Learning How To Learn” 课程，了解了很多关于大脑科学，和学习心理学的知识。为了更好的掌握这些知识，现学现卖，在武汉 Office 开设了两期的 “高效学习” 工作坊。

两期工作坊一方面验证了书上包括 “Learning How To Learn” 视频上讲的理论，也让我如何在设计课程中有了更多的灵感和经验。当然，每一期学习者都会成为我学习心理学实验中的“小白鼠”，当然这是后话。但这也是我逐步开始研究人和人之间学习能力差异性的开始。

随着自己的体验和工作坊的开展，我发现了以下两个常见的学习假象和真相：

假象：学习，只需要买书，看视频，在网上找文档就可以了 #

真相：学习是一个很艰难的过程，找一个好的教练，效果事半功倍 #

如果我们设定一个学习目标，而且我们有验证和度量这个学习目标的方式。从起点到终点，有无数条路径。对于已知的知识来说。最慢的路径就是看书，其次是视频。如果你不是一个长期自学并且严于律己的人，达到学习目标是一个漫长而又痛苦的过程。想想那些你的计划，和执行。这也就是为什么达到健身效果的最有效方式是找一个教练：他最重要的职责是在你容易放弃的时候帮助坚持下来。

一方面，有可能是因为学习过程本身困难，压力很大。另一方面，就是会有其他的事情阻碍你的专注。因此，达到学习目标最快速的途径就是找到好的教练，制定适合你自己的学习课程，按部就班的完成内容的练习和检测。

假象：完成课程，就学会了相应的技能 #

真相：只有你能够教别人，才是完全掌握了 #

“蔡加尼克效应”，是一种记忆效应，简单的来说，就是你不会记得已经完成的事情，而是一直记得未完成的事情。也就是说，当你完成了学习过程，你会忘记之前学过的内容，因为它对你的重要性已经不强了。这点很容易理解，尽管你高中大学很多课当时考了高分，但现在让你再考，你会忘记当初学习的内容。因为，学习的目的是为了考试和分数，当考试和分数这个压力没有了，你自然会把内容忘记。

我自己的亲身经历也能提供证据，在我刚加入 ThoughtWorks 的第一年的14个月里，我一口气完成了 Coursera 的 9 门在线课程的认证。然而现在让我回想起来，记住的并不多，因为缺乏实践和使用，它们随着我回收的神经细胞一起回收了。

因此，不断的复习，并且通过教别人的方式复习是最有效的验证和巩固方式，你不光能够在准备内容的时候巩固自己所学。也可以在和学员的交流中发现自己需要补充的知识。

现有课程的问题 #

很多的课程以在线材料的方式出现，包括视频课程，在线文字课程。这种方式的缺点在于只有输出，学习者是否获得了对应的知识和技能是无法验证的。它们并不是一个“学习体验旅程”，而是学习体验中的元素。学习体验旅程的中心是学习者。如何围绕学习者构造的，而不是内容输出者。

如何验证学习的效果？ #

在线课程无法证明你“掌握”了，但可以证明你“了解”了。当然，这个“了解”，一定程度上处于学习者的主观判断。而一场考试则是考验你是否“记忆”了。对于在线课程来说，只能确保输出，但很难确保输入。

因为存在两个问题：

一方面就是我们无法控制学习者的状态，无法及时的给学习者帮助和反馈。另一个方面就是学习者掌握的内容如何确认学习者真的掌握了，或者能够验证掌握的程度？

因此，课程一定要设计出能够帮助学习者自身度量自己掌握程度的验证方式，目前比较好的量化效果，就是考试。

如何验证学习的价值？ #

这个课程给学习者带来的价值是什么？对于学习者来说课程往往是一个 0 到 1 的过程，而从 1 到 100 则需要个人的精进。而且，每个人的诉求并不相同，如何保证每个人都有所得，就需要设定好学习者期望。

所以，提供的价值对于学习者来说很有限，但如果养成了良好的习惯或者正确的认识，则能加速个人 1 到 100 的过程。因此，课程的设计一定要能够做到以下两点：

1. 针对特定学习者，内容能够由浅入深，并且可以度量。
2. 提供由浅入深中“不变”的那个部分的专项训练。
3. 在召集学员的时候明确以上两点。

因此，课程做到保证“师父领进门”，而“修行在个人”就只能靠学员平时在工作中对学习内容的应用了。

设计一个 MVP #

根据以上我的经验，再加上“精益创业”的熏陶，我就开始进行第一个 MVP 的设计和实践。

首先采用逆向工作法，从学习者的可度量结果出发，反向推导应该设计什么样的内容，以及如何掌握。利用“蔡加尼克效应”，让工作坊的内容在课堂上完成不了，利用持续性的压力迫使学习者不断在脑中复习。通过学习者的反馈进行不断的调整。

既然叫做四周四架构，目的就是要四周的时间在 AWS 上搭建四种不同的应用架构，从最简单的应用开始，逐步增加内容。并用实际的场景驱动架构的演进。

MVP 的用户是没有 AWS 经验或者 AWS 经验尚浅的 Developer，使他们在学习之后能够达到以下效果：

1. 了解在 AWS 上端到端构建应用的过程。
2. 学会 AWS 上常用服务的使用要点。
3. 实际构建 CI 服务器并亲自完成 CD 过程。
4. 了解基础设施即代码并自动化以上三点内容。
5. 对实际的工作产生积极的作用。

我邀请了我的 Sponsee 赵朝朝和张冬毅帮我提供了知识体系的内容。整个工作坊包括以下三方面内容：

1. 基础的 Ops 知识：网络、安全、CDN、操作系统、命令、脚本等。
2. AWS 的组件知识：通过一个端到端的应用搭建，了解每一个 AWS 服务组件的用法。
3. 真实环境下的最佳实践：基础设施即代码，CI/CD，基础设施流水线，技术雷达相关条目等。

并且，从“安全第一”的角度下对每个课程进行设计，启发学习者对安全问题的思考。所以根据我自己的经验，我进行了如下的设计

工作坊的设计有以下几个原则：

1. 安全：每个实践都会首先从安全的角度考虑。（Security In Our DNA）
2. 自动化：从第一周开始到最后一周都是采用基础设施即代码自动化完成。
3. 最佳实践：考虑常见场景，并讨论最优解决方案。
4. 技术雷达：本课程采用了最新一期技术雷达的相关工具和技术。
5. 作业实践：每次课程都留有作业，根据时间分为小作业（平均6个小时）和大作业（平均10个小时）。
6. 提升自学能力：在工作坊中通过 Lightning Talk 分享知识点，通过分享和反思提升自学能力和团队学习能力。参与本工作坊的学习者要成为下未来工作坊的 Coach，”以教为学“，通过教来检验自己的学习和掌握成果，并巩固复习其中的知识。

AWS 组件和服务： 管理类：CloudWatch, CloudFormation 安全类：IAM，KMS, Certificate Manager 网络和内容类：Route 53，Cloudfront，VPC, Subnet，Internet Gateway, Security Group，API Gateway 计算类：EC2, ELB, AutoScaling Group, LaunchConfiguration，Lambda 存储类：S3 数据库：RDS，DynamoDB

工具： SaaS 服务类：cloudping.info, cloudcraft.co, flood.io 运维工具类：ansible, docker, crontab 应用工具类：hexo, jenkins, wordpress, serverless framework

工作坊所用到场景实践和工具：

1. 基础设施即代码
2. 基础设施流水线（请参考 第 17 期技术雷达）
3. Flood.io 负载测试 （请参考 第 17 期技术雷达）
4. 数据库的备份和恢复
5. 自动化水平扩展

第一次获取反馈 —— 第 0 期学习者 #

最开始的时候我召集了几个熟识的同事，包括同一组的同事。运用每周二、四的晚上 2 ~ 3 个小时来进行分享和理解。同时布置作业，所以每堂课分成4个部分：

1. 作业点评 - 30 分钟：除了第一次课外，
2. 学习者 Session - 30分钟：学习者 Pair 或者独立完成一个 Session，Session 的 题目除了布置的内容以外。更多的是课堂上产生的问题。例如 HTTPS 的原理，加密解密，基本的网络知识
3. 本次内容和本次作业 - 30 分钟：25分钟用来讲解本次的内容，5分钟用来留作业。
4. 收集反馈 - 30分钟：收集学习者的反馈。

MVP 需要验证以下问题：

1. 时间是否足够
2. 难度是否适当
3. 作业占用学习者的精力的多少
4. 布置的 Session 是否达到效果
5. 验证 AWS 支出会有多少

首先，我挑选了一些学习者。看看对 AWS 熟悉程度不同的学习者对课程内容难度的消化情况。其中，2名零基础学习者，2名有一点 AWS 使用经验的 Dev，以及开始或者正在 AWS 上做 Ops 的学习者。

其次，采用“目标驱动的自学”，并采用 Session 和作业的方式进行验证，使得学习者通过多感官刺激记忆住学习的内容。并在过程中，借由驱动自己解决新出现的问题来提升自己的学习能力和效果。

最后，利用“蔡加尼克效应”持续不断的在学习者的大脑中增加“未完成”的印象，使得这种压力和记忆有足够的时间来留下学习印象。

通过第一次的实践，我获得了如下结果：

1. 内容太多，Workshop 内的时间并不充裕。第一期完成的时间比预期（4周）要多，内容进行了 80% 花费了7 周的时间。
2. 难度偏高，除了课时内容，需要每天占用至少 2 小时来完成作业。如果增加学习压力的话，效果未必好，疲劳度会提升，影响工作和进一步学习。
3. 学习者自己讲的 Session 能够很好的传递积累和学习知识。
4. 工作坊的支出在 78 元附近，包含一个自己的域名（9 美元），采用 Free Tier 政策则能省下更多。

获得了以上的结果后，我就开始准备第一期学习者的招募计划。

第二次获取反馈 —— 第 1 期 学习者 #

当第0期还未结束之际，我就开始招募第一期的学习者，为了保证效果，限定10名学习者（面向 Office，从不同的5个项目组依据性别比例随机选择2名）。此外，加上我所在团队的成员，共有20人报名。

根据第一期的经验，同时删减第一期的内容，减少作业量，

第一期学习者需要验证以下几点：

1. 什么样程度的学习者对这个课程感兴趣？
2. 调整过的内容是否合适？
3. “蔡加尼克效应”对 0 期学习者的影响是否有效？
4. 0 期学习者是否能够采用教别人的方式完成知识的巩固？
5. 学习完成后给项目和自己能给自己带来多少真实的提高？

邀请 0 期的学习者成为第 1 期的 Coach 有两个动因：一方面是验证蔡加尼克效应的真实效果，另一方面是巩固第 0 期所学的知识。

在过程中，根据学习者的反馈，对课程的设置及时进行调整。分别增加了一次作业讲解，为了让大家更加熟悉基础设施即代码。此外，为了阶段性巩固学习成果，将第六周改为了一次“期中考试”，以巩固之前所学。期中考试的结果还是反映了一些问题的，于是在这一期课程进入尾声的时候，我增加了期末考试。并且计划将期末考试的时间推迟两个月左右，来看看考试效果。

针对整个学习的内容，我把考试分为了笔试和上机两个部分。主要目的是能够运用 AWS 服务完成一个应用端到端架构的基本原理，次要目的是检测学习者对学习内容掌握的清晰程度。因此，笔试部分为 40 道不定项选择题，每题 1 分。这种题目的要求比较高，只有清晰掌握了知识，才可以做全对。40道题里的难度设置为：10 分“送分题”，关于工作坊所学内容的一般性常识，10 分基础题，只要参加工作坊完成过作业就可以答对的题。10 题难题，答案中有所混淆，十分熟练才可以大队。10题陷阱题，目的是为了矫正认知，所以基本上一定会做错。

上机部分以第 3 周，也就是工作坊中最难的架构为场景，设计了12个考点，每题 5分，共 60 分。 简单，中等，困难各 4 道。简单题目就是直接指出在 AWS 中要完成的事情，再一次巩固学习内容。中等题目是设定一定目标，提示 AWS 组件，而完成的内容需要自己来实现。困难题目只是表明目标和检测方法，没有任何提示。这样从分数上来说，就可以收集到学习者的结果和课程设计期望之间的差距，以便下一期设计好课程。

在进行正式考试之前，我分别找了两位同学进行“试考”，以确保题目正确并达到想要的效果，避免出错题。

通过第1次的实践，我获得了如下结果：

1. 这个 MVP 依然很大，将学习时间碎片化并不利于对内容的掌握。学习内容对于目标的完成来说并不利。
2. 吸引到的学习者都不是专业做 Ops 工作的，知识结构上存在短板，但和 AWS 有一定交集，并没有经过系统的学习。
3. 人数必须在10人以内，否则时间会被分散，不利于集中使用，难以达到预期的效果。
4. 内容很紧凑，如果中间有一次没有来，之后来的可能性很低。
5. 课程时间太少，作业完成程度不高，加之缺乏练习，遗忘很快。“蔡加尼克效应”此处失败，在于学习者对这件事情的重视程度上。
6. AWS 零基础或者具备基本经验
7. Session 占用的课上时间会导致拖堂。如果按时结束，则内容则完成不了。
8. Lambda 的部分所需要的时间比预期的更加长，而且场景有点复杂。
9. 考试是非常有效的验证学习结果的方式。
10. 通过考试发现，对内容的掌握程度和自己的已有知识关系很大。也就是说，分数高的学习者，工作中也在做类似的工作。分数低的学习者，学习内容能给她带来的作用很有限。

即将推出的 AWS 四阶工作坊 #

第 1 期开始的过程中，我不断在度量和总结，并且依据反馈及时调整了课程的设置以及内容的增减，以改进这门课的设计。接下来的第 2 期课程，会有以下变化。

增加了课时：每一个架构都由 16 个学时构成，按照 2 天 * 8 小时的方式计算， 4 周 总计需要 64 个学时。这 64 个学时可以自由安排：可以是一周内的5个工作日，也可以是两个周六周日，也可以是四个周六或者周日。这样课程可以满足更多场景的需要。因此，这个工作坊就不能再叫 4 周 4 AWS 架构了。我把内容再次切割成更加轻量级的单元，学习的压力更小，效果更佳。

此外，在设计考试的时候这让我想到了考驾照。于是，我重新修订了目标和课程名称。将四周四 AWS 架构 改称为“ AWS 技能水平资格认证”（以下简称 “AWS 老司机驾照”），把原先的 4 周 4 AWS 架构变成科目一，科目二，即将增加的中高级内容（正在开发）则放到科目三和科目四中。

我把原先的 4 周四架构拆成 两个部分，Serverless 部分单独成为一个两天的工作坊，暂时剥离 AWS 老司机。剩下的内容再次删减成两个部分，一部分是简单的 EC2 Server 的设计和使用，重要强调基础设施即代码能力（一阶），用两天的时间完成。另一部分是真实的 Web 应用场景，把独，CDN，VPC 规划 和 RDS 放到另外两天的课程（二阶）。

第二期的设计如下：

1. 重新定位的学习者目标：巩固 AWS 的每一个应用架构的场景和知识。
2. 更小的学习压力，更容易的输出和度量。
3. 采用周末一天或者两天，全天的方式，集中的完成一个内容。
4. 更多的课堂指导实践的机会，当堂消化内容。
5. 每一次一定会有上一次的内容相关的考试，通过反馈来校正和巩固自己的学习效果。

这一次的效果和反馈如何呢？期待你的加入和分享。

与此同时， “AWS 老司机驾照” 的科目三和科目四正在开发中。目前的计划是采用 Terraform 构建一个 Kubernetes 集群，并且引入 Spinnaker 作为流水线，部署一个 微服务架构的应用并引入 Chaos Monkeys 做可用性验证。全程会采用技术雷达推荐的实践和工具，并且同样结合真实的项目场景进行驱动。