Questions in 3 Minutes

    • 能请你给我画张系统图吗?(你的目的是理解系统图中所有方框都是干什么的;先从离客户最近的方框入手,询问它存放了什么数据,它干了什么,它接收和发送了什么数据)
    • 按照你的方式询问所有方框的情况,直到了解了它们都是干什么的(寻找我们讨论过的东西,如服务分离、服务链、索引和扩容)。结果从这个方框传到那个方框的延迟是多少?
    • 你应该能通过通览系统图来识别出服务链,询问这类设计的必要性,并弄清楚整体响应时间是多少和最坏的情况下是多少。如果你发现图中有个地方的响应延迟非常长,询问怎样才能通过缓存、纵向扩容该服务,或将部分逻辑分到其他服务中去来提升它的性能
    • 可以扩容到N吗?想想当你使这个数字变得无比巨大时会发生什么。我把“无比巨大”定义为每秒有1万个请求,或者1亿条客户记录,抑或每天1百万个订单。那么你的工程团队需要干什么?增加更多的A方框就够了吗?去掉B方框有什么影响?
    • 了解你的系统:包括了解它会如何出错并如何恢复。确保自己了解到了系统的哪些部分会产生致命的错误,并让工程团队优先考虑对保证这部分的稳定性进行投入
    • 我们是围绕组织边界或系统边界来架构吗?有时你会发现 SOA 反映的是公司的运营方式,而不是数据或应用程序的结构方式。而由于公司的组织结构不是遵照摩尔定律设计的,所以要避免这样的设计。当出现一些团队难以协作而导致多余的或不正常的系统被构建出来时,检查上面这一点并主动应对

    摘自 So, about this Googler’s manifesto…

    • People who haven’t done engineering, or people who have done just the basics, sometimes think that what engineering looks like is sitting at your computer and hyper-optimizing an inner loop, or cleaning up a class API. We’ve all done this kind of thing, and for many of us (including me) it’s tremendous fun. And when you’re at the novice stages of engineering, this is the large bulk of your work: something straightforward and bounded which can be done right or wrong, and where you can hone your basic skills
    • But it’s not a coincidence that job titles at Google switch from numbers to words at a certain point. That’s precisely the point at which you have, in a way, completed your first apprenticeship: you can operate independently without close supervision. And this is the point where you start doing real engineering.
    • Engineering is not the art of building devices; it’s the art of fixing problems. Devices are a means, not an end. Fixing problems means first of all understanding them — and since the whole purpose of the things we do is to fix problems in the outside world, problems involving people, that means that understanding people, and the ways in which they will interact with your system, is fundamental to every step of building a system. (This is so key that we have a bunch of entire job ladders — PM’s and UX’ers and so on — who have done nothing but specialize in those problems. But the presence of specialists doesn’t mean engineers are off the hook; far from it. Engineering leaders absolutely need to understand product deeply; it’s a core job requirement.)
    • And once you’ve understood the system, and worked out what has to be built, do you retreat to a cave and start writing code? If you’re a hobbyist, yes. If you’re a professional, especially one working on systems that can use terms like “planet-scale” and “carrier-class” without the slightest exaggeration, then you’ll quickly find that the large bulk of your job is about coordinating and cooperating with other groups. It’s about making sure you’re all building one system, instead of twenty different ones; about making sure that dependencies and risks are managed, about designing the right modularity boundaries that make it easy to continue to innovate in the future, about preemptively managing the sorts of dangers that teams like SRE, Security, Privacy, and Abuse are the experts in catching before they turn your project into rubble.
    • Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.
    • All of these traits which the manifesto described as “female” are the core traits which make someone successful at engineering. Anyone can learn how to write code; hell, by the time someone reaches L7 or so, it’s expected that they have an essentially complete mastery of technique. The truly hard parts about this job are knowing which code to write, building the clear plan of what has to be done in order to achieve which goal, and building the consensus required to make that happen.