申明
本站点所有文章，仅代表个人想法，不代表任何公司立场，所有数据都来自公开资料
转载请注明出处
从最新的 re:Invent《BPF performance analysis at Netflix》开始关注到 Brendan Gregg，并偶然发现他的个人博客，追了一篇又一篇 Linux 性能相关的技术、工具和在 Netflix 实践的博文，非常欣赏像他这样爱钻研，爱分享以及享受 Linux 性能相关工作的状态，去年底他还出版了《BPF Performance Tools》 一书，推荐一读；在他的博客页，还发现他写过三篇在 Netflix 的工作体验（2015 & 2016 & 2017），这几篇真实的亲身体验帮助硅谷的工程师了解 Netflix的自由和责任的文化内涵和以及真实的工作状态；
从这周开始，在 AWS工作进入第五个年头（满四周年），面对不断的弹窗拷问《你对目前的工作还满意吗？》，也来忆苦思甜下，学习 Gregg 跟大家唠唠在 AWS 做解决方案架构师的体验，所有内容都是个人想法和感受，跟公司 HR 和 PR 无关。
四年 AWS 是什么“资历”？
在公司呆满五年的同事，工牌要换成黄色，我们笑称”黄牌“警告，警告你别躺在“资历”薄上，牢记 Day 1 不懈怠，这里只有跑的快和慢，没有人在意你的“年轮”。
按照亚马逊招聘高标准，新人的能力要求是要超过该团队一半人的水准，因此，团队尤其是技术团队，总是长江后浪推前浪，老人会不断从愚昧山峰被推到绝望之谷，比如近期技术大群冒出一个新秀翻译出版了四本技术书籍涉及机器学习、无服务器、DevOps以及监控，亮瞎了大家的双眼；又比如架构师团队有不少国内互联网公司的 CTO 级别的大牛加入；
AWS 的客户无论是技术面还是实际生产场景都很新鲜刺激，比如团队一位一年不到的新同事，今年开始一直帮助客户处理大数据，容器，数据库等非常深入的技术细节，客户类型横跨游戏，电商，工作室等等，他越来越享受这样的挑战和过程。
在这里遇到以前从没想过的客户群体，年轻的 CTO，大数据和 算法团队，高速发展即将上市的创业公司，转型互联网业务的老牌企业客户，比如年轻的英语流利说，在美国高速开疆辟土后来被头条收购的短视频 Musical.ly，火热的社区电商小红书等等，能和这些公司的团队一起沟通交流学习，以及提供技术支撑，一直是我认为这份工作的最激动人心的地方；
跟 Netflix 特别关注的 《自由与责任》文化类似，从招聘开始，候选人就被提醒要重视亚马逊十四条领导力准则，如果来过亚马逊 AWS 办公室，大家会发现，领导力准则无处不在，这些准则贯穿所有人的日程工作，外部协作以及内部协作；
https://amazon.jobs/zh/principles
回想起 2016年那会准备面试的时候，纸上画了许多思维导图，用领导力准则重新组织思考自己过往的工作经历，那时虽有硬凑之嫌，但确实多了一个角度来总结自己过往的行为和思考；这些年也累积面试超过了 100人次，越发体会到领导力准则是一个双向沟通桥梁，公司在每个候选人都付出足够的时间投入，互相确认是否是一个合适的匹配；招聘工作在亚马逊被认为是非常重要的贡献，“选贤育能”是十四条领导力之一，所有加入满 6个月的员工都要求参加学习如何主持各种面试环节。
解决方案架构师这个角色，特别看重这几条 “Learn & Be Curious 好奇求知”、“Bias for Action 崇尚行动”、”Invent and Simplify 创新简化“、“Ownership 主人翁精神”以及“Deep Dive 刨根问底”，对照下，是否跟你的初心一致？
持续学习和提升
2016年一报道，就被发配到北京闭关 3个月的学习培训，直到通过了内部残酷的“大师”流程和通过4门考试持证之后才能正式上岗，可见从招聘开始，到正式上岗，面对客户的架构师岗位的要求，是保持很高的要求（Bar）的；那段时光彻底掉入绝望之谷，尤其是关于网络，比如专线、BGP、路由、VPN这些更偏底层的技术栈，对我而言，几乎是一个全新的领域，还涉及复杂的现场施工和第三方合作伙伴，直到后来的几个真实的客户场景的实践，才从绝望之谷慢慢爬上来，建立信心；而 798 的时光故事，成了所有新人共同的回忆。
这也是当时感觉特别不可思议的地方，AWS 居然创造了如此良好的环境，使新人排除很多外在干扰，彻底静下心来学习，而且不仅仅是解决方案架构师，所有角色包括商务拓展经理岗位（技术销售）也一样要求，因此，初到公司，我发现首先要挑战的是一长串类似闯关的清单，一路打怪升级，这种机制是新人快速成长和融入的最佳实践，这几年从开始的手工记录到现在的系统化跟进，在自我学习提升的道路上，AWS 一直没有停止过投入；
在 AWS 大家的“统一语言”，除了领导力原则，还有围绕客户，就具体的方案架构不断探讨和内部推进，估计很多人一开始不适应的就是 AWS 太“技术范”了；
AWS 新服务和新特性每年都会在 re：Invent的时候大规模发布，2019年创新特性已经接近 2000项，云服务如此高速的发展，要求架构师一定要以发展的眼光来不断更新自己架构理解和细节迭代，今天的不可能，说不定在明天就普遍支持，云服务的广度和深度，要求架构师除了掌握知识的广度，更要求对某一方面的深度专家型钻研，内部有非常多的技术和行业领域垂直虚拟团队，每个架构师至少要求在某一个领域成为专家，而几乎所有的专业领域社区，都定期有各种分享和培训机会，包括本地和全球定期的技术研讨会。
面向客户的一年一次的技术峰会在年底的时候拉斯维加斯举办，也是全球云计算行业技术人员的盛会，re:Invent2019 总计超 65,000人现场参加，超 3000场技术演讲；内部每年也会有一次全球各业务和技术团队互相碰撞的研讨会，参考《别人家的年会，自家从不停歇的学习季》了解一些详情，内部的会除了内部的技术和非技术分享，可以面对面约谈特定云服务的开发团队，海外客户的技术支持团队等加深交流和协作。
不确定性挑战和积极行动累积信心
“故障总是在意料之外，情理之中发生” 我们 CTO 沃纳的一句经典。
现实情况，技术优化的优先级常常排的比较低，随着业务的发展，客户通常累积不少技术债务，系统和应用的现代化之路不好走，因此架构师团队需要和客户持续为优良架构而努力，构建高健壮性韧性系统，冗余，自动恢复，弹性，混沌测试，主动发现和消除系统的脆弱点。
在 AWS 我们经历了太多突发的挑战，但总能迅速沟通，梳理出事实和改进计划，进而快速采取行动，很多时候，撸起袖子加油干（Bias for action）之后，很多挑战的上下文会越来越清晰，从而逐步构思和形成我们的解决方案。
说一个发生在 2016年的例子，那一年《电信业务分类目录》正式将云计算服务纳入电信增值服务目录进行管理，并于3月1日正式施行，在国内提供云服务需要按规定申请许可证，新的法规对于云计算服务的管理有了明确的要求，一直是我们所期盼的，但真正落地，对公司尤其是一家外资企业的挑战是巨大的，因为没有现成的参考，需要团队既要接地气满足新的合规要求，又要创造合适的运营模式同时得到西雅图总部的认可；我当时刚加入不久，心慌的很，当时业务被迫采取了休克疗法，需要尽快满足合规要求才能开展新业务；但管理团队第一时间就跟大家透明沟通，非常坚定深耕中国服务客户的信心和决心，并定期更新事件进展，一线团队虽有疑虑，但表现的非常专业，一如既往的服务好现有客户，保持积极的沟通，很快在 8月1日，发布公告和光环新网达成更广泛的合作，从而新的运营方式符合了电信管理法规，业务摆脱停摆挑战，正式迈入正常快车道；这样的高效处理过程是我以前没法想象的，这里拥有创业公司的氛围发展速度。
另外一件客户专线高可用架构的案例，也很好的教育了我，遇到挑战，要迎面而上，事情往往在团队抽丝剥茧，积极推动下取得意想不到的成果；事情缘由是一个金融客户的混合架构，跟 AWS 构建了两条冗余的不同运营商的专线，客户不能容忍本地和云端的网络在业务时间内有任何中断不可用发生，但事情的复杂度在于，一条专线，涉及多方，比如 AWS 侧的专线服务，路由器，接入点的设备状态，运营商的线路和设备状况，客户自己机房的设备状况等等，这里有非常多的故障点，任何一个点的故障，首先要第一时间发现，发现之后还要能尽可能自动化切换，怎么破？当时我还处于跟班实战学习状态，我也在思考，如果我碰到这样的挑战怎么办？老实说，在遇到自己不擅长的领域，我的第一反应，太复杂，直接“怂”了；但前辈很好的给我上了一堂课，首先积极沟通和向前推进，先从 AWS 侧思考，如何监控端到端连通性，再验证演练发生故障，专线切换如何做，能不能成功，最后请客户支持，建立一个多方合作响应机制，发生故障第一时间，各方确认是否自己的节点有故障发生，并通报处理进度；整个解决方案非常成功，既有技术层面的从零到壹的端到端监控脚本，故障切换架构设计&故障演练，还有促进多方合作，配合客户一起满足业务可用性要求，那一刻，我相信不仅是我自己感受到，客户也感受到，这群人不打诳语，技术扎实，渴望帮助和成就客户。
团队信念
每一年都有新的变化，老大也一直教育我们，变化本身无所谓好坏，保持开心(Have Fun)、爱心(Customer Obssession)和好奇心(Work Hard & Make History)，成就客户，成就团队也就成就了自己。
如果你也想加入，请参考招聘帖！新一轮全国招聘，海量职位等你来pick～了解更多岗位信息和投递简历。
