许式伟的架构课
许式伟
七牛云CEO
立即订阅
20092 人已学习
课程目录
已更新 72 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (9讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
许式伟的架构课
登录|注册

48 | 事务与工程:什么是工程师思维?

许式伟 2019-10-11
你好,我是七牛云许式伟。
服务治理的目标,是保障软件提供 24 小时不间断服务。服务治理没有简洁的抽象问题模型,我们需要面对的是现实世界的复杂性。
保障服务的健康运行,必然有大量的事务性工作,运维或 SRE(网站可靠性工程师)这样的职业也由此诞生。

事务与工程

但是如果我们停留在事务中不能出来,那么随着我们所服务的用户数量增加,必然需要招聘大量的人员来应对繁重的事务工作。
事务性的工作不会总是让人不开心,特别是工作不太多的时候。已知的、重复性的工作有一种让人平静的功效。完成这些事可以带来一种满足感和快速胜利感。事务工作可能是低风险低压力的活动,有些员工甚至喜欢做这种类型的工作。
但是我们必须清楚,在 SRE 所扮演的角色中,一定数量的事务工作是不可避免的,这其实是任何工程类工作都具有的特点。少量的事务存在不是什么大问题。但是一旦事务数量变多,就会有害了。如果事务特别繁重,那就应该非常担忧了。
如果花在工程项目上的时间太少,你的职业发展会变慢,甚至停滞。我们可以鼓励那些做脏活累活的人,但仅仅限于在这些工作不可避免,并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏活累活实现自己的职业发展。

把问题彻底解决

取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • humor
    “经验当然是有价值的,但过于相信惯例就会抑制创新能力。”
    对于这句话不理解哎,许老师帮忙看一下啊
    1、什么是过于相信惯例呢?如果对于一个问题,已经有了一个经过验证的惯例解决方案了,那我们还需要再去尝试其他非惯例的解决方案吗?如果去尝试其他解决方案可能会导致费时费力,最后使用的解决方案的效果有很大的可能还不如惯例解决方案。
    2、创新能力与经验是呈负相关的吗?很多公司都很强调创新能力,那为了拥有比较强的创新能力,我们是不是就应该不去学习前辈的知识经验惯例了呢?但是不学习知识经验的话,可能连最基本的问题都解决不了了。

    作者回复: 1、是否应该创新与你的目标定义有关。如果你觉得花费几天时间从杭州到上海已经很好了,那么马车就足够了,但是4个小时你就得创造汽车,如果50分钟就要创造高铁。
    2、学习前辈经验不能局限于技能本身。汽车和高铁并不是无中生有产生,也是前辈经验的产物。有种学习叫迁移学习,把旧经验应用到新领域中,大部分创新由此而来。

    2019-10-11
    9
  • 往事随风,顺其自然
    这个工程师地位问题,我要说句,看在什么公司,互联网还是传统行业,传统行业很低下
    2019-10-11
    1
    5
  • 靠人品去赢
    不是工程师强势,是不强势可能被搞死,一张嘴两三天白干了。你突然来了个灵感要求立刻马上,你有没有考虑对现有业务的影响,工程的复杂度。
    实际上赚钱的业务部门才是真的强势,还是要听人家话的,按照人家的来。但是脱离事务型工作,确实有的时候是一种脱离舒适区的感受,成长是一件逆人性的事。
    2019-10-12
    3
  • CoderLim
    1、用系统化结构化的方案 close 问题;
    2、反思自己做的是新事,还是简单的重复;
    3、代码只是工具。
    2019-10-11
    3
  • 张裕
    重复性的事务确实是很多人的舒适区,很多时候会成为工程化改进的阻力,比如在测试部门推广测试自动化,在研发推广全栈开发。老师能不能分享下在推行工程师文化时的一些经验?

    作者回复: 谈收益和目标,不从技术出发

    2019-10-11
    2
  • 日拱一卒
    1. DRY,Don't Repeat Yourself。
    2. 做事要平衡短期价值和长期价值,重复性的事务工作,没有长期价值,但往往是“舒适区”。
    3. 工程师文化或者说工程师素质,不仅仅局限在软件开发领域,想一想工程师出现的时间,要远早于软件开发。
    4. 工程师素质强调的是解决问题,而且是永久的高质量的解决问题,这在任何领域都是普适的。
    2019-11-18
    1
  • 丁丁历险记
    我作为一个客户,可以保证,七牛的销售是绝对有地位的,几年前去找气流的时候,服务热情满满。现在再去找七牛,基本上对你爱搭不理。

    作者回复: 有可能是客户交接出了问题?可以加我微信(xumingyu07)我们聊一下。

    2019-11-08
    1
  • Geek_88604f
    工程师文化是大众文化还是精英文化,不知道老师是倾向于哪一种?因为从现实情况来讲大多数公司中的工程师只负责某个模块或微服务的开发,他可以引入新技术把模块的开发工作到极致,但是可能缺乏全局视眼而没有往更高的层次发展。
            从另一个角度来讲,主要靠经验积累的技术工作是否属于老师讨论的工程师文化的范围?(例如:芯片行业的核心设备光刻机,其核心中的核心是光刻镜头,出人意料的是该镜头并非高精尖的机器打造的,而是人工打造的)
            另外,工程师文化和工匠精神有什么区别和联系,老师能不能谈谈这方面的看法?

    作者回复: 我觉得工程师文化不在于精英还是大众,在于思维方式。也许有人还不太擅长彻底解决问题,但是需要建立彻底解决问题的思考方式,以此获得不断改善的机会。工匠精神强调的是追求极致,工程师文化不只是要极致,它更在意极致的可复制性和代价。光刻镜头不能机械打磨,只是临时状态,并不代表以后不能,坚持这种想法这就是工程师文化。

    2019-11-05
    1
    1
  • 葫芦娃
    从小受的奉献精神教育,对个人职业发展有时候反而有害。应该花更多时间在有价值的事情上,解决问题同时提升自己,而不是脏活累活,实际上公司没人在乎你的苦劳,尤其传统行业
    2019-10-12
    1
    1
  • Aaron Cheung
    需要关注业务导向
    2019-10-11
    1
  • Dimple
    一个公司各个岗位是彼此协作的团队,工程师并不是特殊群体。销售、技术支持、产品、开发工程师每一个角色都是平等的。每个人都应该秉承工程师精神,把一个个问题 Close,让它不要再发生。不需要显得很忙,忙不代表成就,真正的工程师文化应该是推动整个团队往前走,每个团队成员都在成长。

    这段话我要分享给公司的同事,其实大家都是平等的,都是为了团队而努力,并不存在所谓的优越感
    2019-11-26
  • Eternal
    但是我们必须清楚,在 SRE 所扮演的角色中,一定数量的事务工作是不可避免的,这其实是任何工程类工作都具有的特点。少量的事务存在不是什么大问题。但是一旦事务数量变多,就会有害了。如果事务特别繁重,那就应该非常担忧了。如果花在工程项目上的时间太少,你的职业发展会变慢,甚至停滞。我们可以鼓励那些做脏活累活的人,但仅仅限于在这些工作不可避免,并有巨大的正面影响的时候才会这样做。没有人可以通过不停地做脏活累活实现自己的职业发展

    这段话印象最深刻
    2019-11-23
  • 丁丁历险记
    未能深入理解,流水账笔记先记起来。
    面对现实的复杂性。
    事物性工作,低风险,低压力,事物数量变多就不好了。
    不可避免,有正确意义时做。

    健康公司,业务导向。
    工程师,业务自动化,编码只是一个工具。
    舒适区,不符合工程师文化。
    每天做新的事情,旧的是否有效解决。彻底解决的思维,看中的是自己的长期价值。
    把一个个问题,close 真正的工程师,推动前进。
    少是指数级的多。
    注释代码混乱,功能开关是炸弹。

    复制性, 不确定性中平衡。 寻求本源,不迷信权威。

    工程师思维起到关键支撑。
    2019-11-08
  • 随心而至
    1提高效率,Don’t repeat yourself
    比如,处理单个文本的时候,会不会想到正则表达式;处理多个相似文本,会不会想到用程序解决
    2.知其然,知其所以然。
    既可以一层层抽象上去,在更高的层次解决问题;也可以一层层展开,在更低的层次理解问题,
    2019-10-29
  • 小助手
    这一章哲学性比较强了,
    理解起来有些难。。
    和拜佛求经一样,
    很难凭空顿悟,
    需要一些经验做基础。。。

    留做日后反复参悟吧。。。
    2019-10-24
  • 小名叫大明
    从我的经历看,做到商务,开发,产品平等基本是不可能的。

    举例如下:

    项目型的公司,商务签单就是一个项目,如果有一个比较着急,原本3个月的排期所有程序员加班可以2个月完成[伴随bug多],那么好,以后都是这个标准了,你要再说三个月,人家会说"上次两个月就完成了,这个也着急" (矛盾的本源可能也不是这里,矛盾的本源是工期压缩,所有人加班,待遇什么也不会变,身体垮了,身体垮了不能加班只能请你离开)

    2019-10-15
  • 侯永强
    许老师,看了新的大纲。此前目录中有一篇:《架构范式,基于日志redo undo 设计》。很期待您能补充这么一篇内容

    作者回复: 这块会揉在架构思维中讲

    2019-10-13
  • ky
    工程师以系统化的方式寻求较为彻底的解决方案,软件编码是手段之一,可能也是当今世界最为通用强大的手段。工程师需要不断迭代,不断改进系统以增强事务解决能力。技术的复杂与新奇不足以过于沉醉,能够用来解决问题的思路方才是价值。

    作者回复: 👍

    2019-10-12
  • leslie
    老师今天的课程中“以批判精神、坚持以系统化的思维来把彻底解决问题”这个好像有点说不通吧?是不是编辑又弄错了;不过我觉得“以批判精神、坚持以系统化思维来把问题彻底解决”这倒是真正的工程师思维这确实是工程师思维的真谛;虽然这个做不到极致,不过我觉得可以做到“以批判精神、坚持以系统化思维来把问题解决且无典型隐患”。
         工程师的自我批判精神是必须的:自我批判自我否定-人才能进步;记得大学时参加新东方英文培训时老俞讲的最多的就是自我批判自我否定、相互批判相互否定,然后大家就进步了。一个Team一个技术团队要想强大就必须如此。纵然其中的一类就是在伤害另外一类,案例见得太多听的太多了。
    2019-10-12
收起评论
19
返回
顶部