杰出工程师的职责

Clarke Rodgers（00:11）：
Paul，非常感谢您今天的到来。

Paul Vixie（00:13）：
很高兴来到这里。

Clarke Rodgers（00:15）：
可以的话，请您介绍一下您的从业背景。作为杰出的创新者和思想领袖，您在一定程度上帮助在 DNS 基础上发明了互联网。请带我们了解一下。

Paul Vixie（00:30）：
我确实在早期参与过这一过程，但我不是 Al Gore，互联网不是我发明的。对于 DNS，我一开始只是想让它更好用些。八十年代末时，我在一家小型计算机公司工作，所用的软件很不好用，协议也不是很好理解。所以，做这些一开始只是图自己方便，后来也暂停过一段时间，直到创办了一家公司并重新捡起这些工作。然后当我离开那家公司时，我在安全领域开了一家初创企业。

在此期间，我入选了互联网名人堂并完成了博士学位。我在日本庆应义塾大学获得博士学位，我的学习之旅比较特别，因为我曾在 1980 年从高中辍学。

Clarke Rodgers（01:18）：
哇！我们就这方面稍微展开一下。是什么原因导致您高中辍学，然后又转而进入技术领域？

Paul Vixie（01:28）：
当时我一直在微型计算机领域做兼职工作和零活儿。我的指导老师说：“是的，你明年又要重读高三了”，那是因为我把所有的时间都花在了计算机实验室。

Clarke Rodgers（01:43）：
哇！

Paul Vixie（01:44）：
于是，我意识到情况可能不会好转，我应该离开学校。后来，少不更事的我退学了。但是，是的，这一切都是因为我不是个好学生，因为我在编程上花了太多时间。

Clarke Rodgers（02:00）：
不过，我认为您的选择终究是对的。

Paul Vixie（02:03）：
我对做出的所有奇怪决定都感到满意。

Clarke Rodgers（02:08）：
可以的话，请介绍一下您在 AWS 的职位。

Paul Vixie（02:13）：
我有两三个职位。我被聘为副总裁和杰出工程师，后者是一小部分非常有经验的人。这个职位在很大程度上是自我导向的。要成为副总裁、杰出工程师，具体职责就是找到问题然后着手解决。很少有人说：“Paul，我们真的需要你做一件事。” 因此，对于我们这种规模的公司来说，能够放任我自由工作对我是一项莫大的荣幸，尤其是在 AWS 成立二十五年后，在我不太知道公司发展历程的情况下。这是巨大的荣幸。

这个夏天，我被任命为 AWS 的副首席信息安全官，巧合的是，我还受邀领导首席信息安全官办公室。您可以将首席信息安全官办公室理解为一群高管级解决方案架构师。如果与客户对话时，他们的高管级人员将出席，通常我们的首席信息安全官也应该到场。问题是我们只有一个首席信息安全官，而需要他出席的场合又有很多，所以我们有点像首席信息安全官的后备部队，也就是说，有六个在该领域、该行业顶尖的人才。我一直在与他们合作，事实上，我融入他们是为了与客户取得联系。我想这就是公司邀请我领导那支队伍的原因。

Clarke Rodgers（03:44）：
有什么真正吸引您加入 AWS 的吗？

Paul Vixie（03:47）：
那就是具体的工作内容。换句话说，如果有人请我担任某领域的副总裁并负责某个职能，我会说：“是的，我经历过，也做过。” 但我当前的职位主要是一个技术岗，至少在我的工作职责中，杰出工程师这一部分属于高管级别的个人贡献者。知道我为何对此感到兴奋吗，在我的职位名称中，在其他公司发给我的聘用通知书中，自 1993 年起，就再也没有出现过“工程师”这一词了。随后我一直担任初创企业的首席执行官，虽然一直是一名动手写代码的首席执行官，但仍然不是真正的专业工程师。那不是我在任何公司的主要工作。

如果没有这些初创企业，这才是我本该走的道路。能够重回原点，纯粹做一名个人贡献工程师，这让我非常开心。我没想到我还能有这个机会。他们做了一番工作来说服我。但是，当他们描述了这个职位，有个声音出现在我的大脑，对我说：“是的，你真的很想做回那个职位。” 我那时不知道，我不知道还会有人雇佣我，因为我在互联网和安全行业算是有点名气的公众人物，而且大家公认我比较麻烦。所以，我会认为我做这份工作会太有争议。但他们不这么认为。到目前为止，他们是对的。

Clarke Rodgers（05:22）：
您来 AWS 已经有一段时间了，也已经对公司了解得差不多了。具体而言，您对 AWS 的安全文化有何印象？

Paul Vixie（05:32）：
当我在领导各种初创企业时，我曾向像 AWS 这样的公司出售产品。所有公司的治理几乎都相同，但 AWS 除外。AWS 的安全团队已经运作了很长时间，他们的经历足以证明安全是头等大事，这也不仅仅是一句口号。这句话始终反映在组织结构图中，反映在上下各级运营计划中，反映在上下各级预算优先事项上。

换句话说，当然，我们在这里为客户提供服务，就像任何公司为客户提供服务一样。不同之处在于，我们不会为客户做一些同时会导致他们失去安全感的事情。我们从不忽略安全。这就是 AWS 不同之处。

Clarke Rodgers（06:20）：
那么，例如，当您作为杰出工程师与服务团队深入合作时，您能否给我们讲讲幕后故事，比如在讨论功能发布与安全修复时是否存在冲突？ 还是只是“不，必须进行安全修复”？ 这些讨论是什么样的？

Paul Vixie（06:42）：
我们不会收到这种怨言：“哎呀，如果你因为某些应用程序的安全测试结果等原因而阻止这次发布，我们就赶不及了。我们会错过最佳窗口期的，并且已经在开始错过了。” 这种对话不会发生，而且绝对、明确不允许发生。我们真正会遇到的情况是，有时某件事是“应该”做但不是“绝对必须做的”，我或其他代表 AWS 安全的同事会说：“这会造成问题，而且以后修复的成本会高得多。” 这里的服务团队在该级别上拥有自主权。

他们可以决定什么是重要的，但他们知道，如果存在安全问题，那么我们与他们讨论这个问题一事将记录在案。他们要对此做一些解释。所以是的，有时候会出现紧张局面，因为显然每个人都要服从各自的上级。如果上级说，我们必须在某个日期之前完成某事，那么你就得朝着那个目标前进，我们能理解这种情况。我们不想搞砸任何事。但是我们知道，与我们合作的同事的主要目标是达到他们自己的指标，而我们这边是次要的。

Clarke Rodgers（08:09）：
那么回到您的日常工作方面，也就是管理首席信息安全官办公室。您可以大量接触我们的客户，可以在世界各地与他们面对面或在线沟通。您在 AWS 参与的一项活动是 AWS CISO Circle。您能谈谈这方面内容和您的体验吗？

Paul Vixie（08:30）：
我初识 CISO Circles 时，大概是这样的，有人问我：“Paul，你能去...”，我那次是马德里，“参加一次 CISO Circle 吗？” 我不得不问：“那是什么？我又该去做什么？” 那时我才来这里一年。这可能是比我目前更了解 AWS 和其发展历程的人去参加的。然后我去了。这个活动很棒，因为聚在这里的是一群来自特定行业的首席信息安全官。而且整个过程有点像遵守保密协议，你可以畅所欲言，因为房间里的其他人不会对他人泄露你所说的话。

Clarke Rodgers（09:20）：
这是查塔姆守则。

Paul Vixie（09:21）：
是的，查塔姆守则。在某些情况下，这些人是竞争对手。他们是属于同一行业或同一地区公司的首席信息安全官，他们通常不会分享想法或经验。但是，因为他们在我们公司，我们也在场，所以我们主持了一下讨论，在讨论中加入一些关于各种技术的演讲，然后鼓励讨论，鼓励质疑，最终鼓励彼此之间辩论。

很高兴看到这一场面，因为任何大中型公司都必须要学会从竞争对手的经验中受益。而且我们不应该试图就谁更安全来一较高下，因为如果你和我的公司属于同一个行业，而你却被淘汰，那仍然会让我感到难过，并且这可能意味着下一个被淘汰的是我。所以以这种方式…

Clarke Rodgers（10:24）：
共享信息和最佳实践…

Paul Vixie（10:26）：
是的，我们需要在某些领域并肩作战，即使同时在其他领域竞争。他们最终了解了彼此，明白了在不冒泄露公司机密的风险下，可以给予多少信任等等。该活动的目的是让他们在活动结束后也能保持联系。当然，不可避免有人会说：“那天我在云端使用某个 API 时体验很差”，其他人会说：“但我用起来没问题”。如果他们最终互相抱怨我们的产品和服务，如果出现这种情况，那么我们也应该接受这一点。

如果我们不知道出了什么问题，就无法更好地为客户提供服务。事实证明，这个活动是我们商业情报的一大来源。有时候你会说：“我希望我有…”，有时候你还会说：“实际上，那是存在的。” 我们是一家非常大的公司，进行了大量创新，而且我们确实以任何客户都无法跟上的速度创造新功能或新技术。这是我的工作要实现的，但对我来说，保持这种速度也很难。

因此，我们必须构建这样的客户界面，来搞清楚客户的问题是什么、行业的问题是什么、他们在做什么、他们是如何做的、他们的痛点是什么。我们发现有些同事正在做这件事，但客户不知道他们应该抽出时间定期与我们这些同事会面。因此，如果 CISO Circle 能帮助实现这一目标，哪怕零零星星，也希望能通过口耳相传，逐渐实现这一演变。

Clarke Rodgers（11:59）：
说得太棒了。Paul，非常感谢您今天的到来。

Paul Vixie（12:02）：
这是一场愉快的对话。再次感谢您邀请我。