水管工云指南

大家好！我叫丹尼尔·辛格尔塔里，来自亚特兰大都市区，是一名工业和住宅水管工。我目前正在努力从手工艺转型到IT行业。这是两个完全不同的行业，而且几乎没有什么共同点，对吗？不对。让我用一个最近的例子来说明。

我和一些同事被叫到一个购物中心，去查看综合楼内每家商店都存在的异味问题。到达后，我们什么也没闻到，于是开始查找，但在与几位商店经理交谈后，我们一无所获。当天我们离开了那里，留下了我们的联系方式，并指示经理和员工一旦异味再次出现就给我们打电话。几天后，我们在星期一午餐时间左右接到综合楼一家美容院的一名员工的电话，说气味太可怕了。我和另一个水管工开车过去，果然，这家美容院的卫生间糟透了，奇怪的是我们能感觉到从马桶底部有气流。我们把马桶从地板上拆下来，令我们惊讶的是，发现有一股气流从下水道系统吹出来，想象一下用吹叶机把下水道气体吹到你脸上的情景。

对于不熟悉管道系统的人来说，这种情况根本不可能发生，更不可能。不用说，我和另一位水管工面面相觑，意识到我们俩对这种情况的发生一无所知。接下来的三天里，我们从小区的两端开始，将可能出现问题的区域缩小到两家商户、一家餐厅和一家美容院。

至此，我们已经拆除并重新密封了无数的固定装置，最终决定对这两家店进行“烟雾测试”，方法是从屋顶的两个管道通风口吹入烟雾弹。我们的理论是，只要有下水道气味的地方，烟雾就能进来，只是我们用手电筒就能看到烟雾。我们开始工作，6个小时后就找到了罪魁祸首。有人把商用炉灶的抽油烟机绑在管道系统上，把所有的空气（就像吹叶机一样）都挤进了下水道。不用说，问题解决了，生活继续下去，但这和科技有什么关系呢？继续阅读，你就会明白我在这个项目中是如何顿悟的。

一天下班后，我收到了一位名叫 Forrest Brazeal 的绅士创建的项目的链接，他向我发起了一个挑战，他称之为“云简历项目”。

读完Forrest的说明后，我迫不及待地想尝试一下，因为在那之前我从未在实际应用中接触过任何与云相关的服务。我对亚马逊网络服务（AWS）很熟悉，因为我的一个朋友推荐我了解一下，而且我在接受这项挑战的几周前就获得了CCP（认证云从业者）认证。

目标：

1. AWS Cloud Practioner 认证是参加该挑战的先决条件。
2. 简历需要用 HTML 编写，用 CSS 设置样式，并托管在 S3 存储桶上。
3. 该网站必须通过 Route53 拥有自定义域名，并使用 Cloudfront 通过 HTTPS 进行保护。
4. 网站上需要有一个用 Javascript 编写的访客计数器，并由保存计数的数据库支持。
5. 该数据库需要信息，因此需要配置用 Python 编写的后端 Lambda 函数。
6. 需要一个 API 来充当微服务交互的中间人。
7. 需要为 Lambda 函数编写测试，以确保对未来更改可能导致的中断进行故障保护。
8. 该项目的后端部分必须利用 AWS SAM CLI 从 SAM 模板构建和部署。
9. 需要通过 Github 设置 CI/CD 以应对未来的任何变化。

最后，一篇博客文章描述了我们在整个项目中的历程，以及我对于最初认为“看起来很简单”的项目的最终反思。

我的苦难……我是说旅程！

在深入探讨之前，我想先说一下我在这个项目中的经历有些特别。在参与这个项目之前，我从未编写过一行 Python 代码，也从未在实际应用中使用过任何 AWS 服务。这个项目从一开始就充满挑战，然而我从未想到的是，我的管道经验竟然可以运用到云计算领域。

说说好东西。
一开始我就得为这个项目写一份简历，我从一开始就用HTML写，这样一举两得。之后，我把所有东西都放进了一个为静态网站托管设置的S3 bucket里。到目前为止一切都很顺利，我对目前的进度很有信心。然后我转向了Route 53和Cloudfront，这是我的第一次真正放慢速度。在学习了证书的所有知识，并花了几个小时排查了记录表的问题后，我的网站终于上线了！

当时，我对这个项目感觉很好，不知不觉中就爱上了云。它的实用性和潜在的应用场景让我眼花缭乱！可惜的是，工作繁忙，新冠疫情让我在医院和诊所工作了好几个星期，但这并没有阻止我接受 Forrest 的挑战。

重新安顿下来后，我立即开始着手处理 DynamoDB 和 Lambda 函数。这部分挑战花了我不少时间，因为我完全不知道如何为从未使用过的服务编写代码。几天后，我写出了一个可以运行的函数、一个可以运行的测试和一个漂亮的表格（至少对我来说是这样），然后开始研究 SAM。对我来说，SAM 的学习曲线非常陡峭，原因如下。首先，到目前为止，我都是通过控制台配置所有内容，因为我想熟悉它的工作原理。我以为这样在挑战到基础设施即代码部分时更容易理解。（我个人仍然觉得这对我来说是个不错的选择，并推荐给所有初学者。）最后，SAM 引入了 CORs 错误，这几乎让我抓狂，而这正是管道与云相遇的地方。
经过几天的努力，我在 CORS 方面毫无进展，即使我取得了突破，也只是破坏了其他东西。

所以我买了一块白板。

我像绘制管道系统工程图纸一样，绘制了整个项目，然后开始排除可能存在的问题。说实话，在管道行业，你肯定会遇到很多你不明白、摸不着头脑或根本不可能发生的问题。每当这种情况发生时，我们都会把整个系统拆解成几个部分，直到把搜索范围缩小到几个区域。之后，我们会开始进行必要的故障排除，直到找到诊断结果为止。

这时我突然意识到，我们之间的距离其实并不太远。Python
测试、将代码分块以便于故障排除，以及如何将所有这些服务整合在一起的路线图，与我们排除管道系统故障的原则如出一辙。不妨参考一下我在这篇文章开头提到的购物中心的经历。

首先，问题并不总是以易于理解的方式呈现。就像COR错误和我们发现下水道气体反吹一样，这很不合理。因此，我们从两个方面入手，缩小了搜索范围，就像在编写代码时，模块和注释之间留出空格，这样就可以逐步排除故障，而不必逐行执行整个脚本。然后，我们使用烟雾弹来让问题自行显现，即使这有点不合常规。这类似于代码测试，它可以准确地显示问题所在，但前提是你也设计了测试，而且有时你需要跳出固有的思维模式来寻找解决方案或测试。最后，我们必须为问题实施解决方案，而在我们的案例中，我们必须在晚上实施，以防止业务中断。云也不例外，即使你发现了问题，你也不能在想要修复时就把所有东西都停掉，你的客户或客户群是第一位的。这就是本地测试和测试环境背后的全部意义所在，即减少实际基础设施中出现的问题数量，以防止停机。

考虑到所有这些，我重新开始着手解决 COR 和其他一些问题。 带着笔记本电脑上班几天后，我的堆栈就部署好了，并且运行正常。此时我知道我已经完全解放了，我用 Github 设置了 CI/CD，开始收尾工作，然后联系 Forrest 把所有东西都交了上去。

这个项目中有几个地方让我内心尖叫，但凭借着我从这个项目中获得的技能，例如 CloudFormation、Cloudfront、S3、Route53、DynamoDB、Python、JS、无服务器架构，以及大量其他服务和行业标准，这一切都是值得的。这个项目坚定了我的信念，让我坚信自己进军科技领域的方向是正确的。更重要的是，它为我指明了一条探索的道路，那就是美丽的云世界。

请访问我的网站/简历：https://www.dsresume.com/

感谢 Forrest Brazeal 创建了这次挑战，也感谢您创造了这个机会来结识其他挑战者并与志同道合的人建立联系。