• 关于假期 30 分钟内必须回 dingding 消息的事情,晚上有点兴奋,我多几句嘴。

    如果我是管理层,我会制定一个轮班机制:

    • 每天有一个人轮班,有问题在 dingding@ 他,只有值班那天 Ta 才会注意群消息
    • Ta 来判断事情是怎么回事,对客服等作出响应。如果是可以延后慢慢处理的,直接归档就行,如果紧急的,直接给对应模块负责人打电话
    • 每个人不用每天下班都对手机消息一惊一乍的
    • 很多时候所谓的” 故障 “是临时或无关紧要的,或者值班的人就可以简单解决

    用大腿想一下,每个人都要在下班时盯着群消息,一惊一乍的。这个综合成本有多高,有多少无效劳动和心智消耗,需要加多少工资才能弥补上。

  • 你这个还是 KPI,只是换了一个说法。

    • OKR 是要暴露一个目标 Objective: App 产品和技术系统高质量开发和运行
    • 通过多个 KeyAction 拆解关键步骤和环节,以达到上面的 Objective,核心是要体现出思路、解决方案、关键途径等。
    • keyAction 需要有多个有梯度的 KeyResult,KeyResult 是衡量 keyAction 的执行质量和目标水位,需要给出明确、有梯度、可循序渐进达到的标准,有些目标不是一下就能达到,要分步。

    App 崩溃率万分之一以内

    这个是一个 KeyResult,还应该有对应的梯度, 比如 99% 是勉强及格,99.99 是及格, 99.999 是超越预期等等。

    可是 KeyAction 呢? 如何达到这个目标呢? 通过什么途径? 用什么方法?(建议补充出来,不要藏知识)

    OKR 的精髓是一个思考框架,帮助组织将大的 Objective 拆成小 Objective,并往下层分发。 Objective -> KeyAction -> KeyResult 这些点的落地、拉通、对齐、筛选就是在设定一整套体系、解决方案、解决途径、解决步骤。

    通过提出一个目标,走一遍 OKR 流程,可以引导出解决方案,这是一个方法论,超越 KPI 的地方。

  • 【译】快乐的和平主义者 at 2020年03月21日

    互联网的数据,多跳一层流量减少 80%。 连微信都在想办法减少跳入层级···,不过得看你想要的是什么。

  • 中大厂的大规模分布式系统,微服务、容器化是唯一的出路。一方面是为了复杂度分解,细化协作分工、提高整体研发效率和稳定性,必须要这么做。

    微服务确实能解决很多问题,让很多东西更容易实施。但一旦拆分后,整体的复杂度会提升十倍以上,主要是分布式体系中网络复杂度和链路复杂度。这需要有相当强大的基础设施来降低这种复杂度,主要是强悍的框架和基础库、pass 能力、数据采集、基础服务、工具链。最难的是要让这些东西保持稳定性和迭代能力,这需要堆非常多的人,一个部件都需要一个团队。

    估计你这边人力资源投入不够,这套东西又烧钱又耗人力。

  • 一文理解 Redis Cluster at 2020年03月14日

    我重新上传一下

  • 直播 -- 弹幕系统简介 at 2020年03月09日

    你们 router 的定位是什么? 如何设计的,为啥要广播。

    我问了一下 bilibili 实际使用,本文中 Router 的设计有些直接废掉了,有些换成了 redis,将 Router 逻辑直接合到 logic。 因为有状态的 Router 一旦挂掉非常麻烦,必须要做高可用,数据还得做强一致性。

    其他节点挂掉后,直接重新拉起来就行,影响不大。

  • 从 LRU 到 LIRS at 2020年03月08日

    有个 “重复的块不算” 的表述,但前后没有统一,导致少了 1

  • 用了较大的成本去增加自己 “贪玩” 的成本,也许可以尝试从根上去解决问题。 比如分析迷恋手机的原因是什么? 是对信息的焦虑,还是其他等等,针对性地采取策略。 解决了这个,就不用太麻烦了。

  • 很多技术 just 工具而已,非高科技的程序员是工具人。

    各个互联网公司用制造业的手法,将流程强化、动作固化、标准细化,追求高效率、低成本。

    人只是运转机器中的螺丝和零部件,各个职业经理人做的事情就两件: 1.搭建机器 2.让各个部件能更容易被替换。

    其实纵观整个行业,除了极高水平的科技外(这个能改造规则), 对公司价值最高的都是: 销售&营销。

    IT 部门算个啥呢,本来就是底层的执行层,被告知要干啥干啥,产品经理把逻辑和图都给你准备好了。

    知道要做啥&为什么要做&如何选择优先级,远比执行本身更有价值。

  • 从 LRU 到 LIRS at 2020年01月18日

    感谢你的反馈

  • 一起学习,感谢你的回复

  • 直播 (上) -- 底层逻辑浅析 at 2019年10月29日

    在有直播业务的公司搬砖。 其实直播那套眼花缭乱的业务都是很 “成熟” 的技术应用,一般技术团队都能搞,稳定性就看公司的基础设施建设了。 核心的是,音视频采集、加工、传输、分发这套工业流程体系,就是传说中的推拉流。 这里面有无数的算法技术智慧结晶,稍微了解了一下膜拜不已。

  • 这个不存在优化问题,表结构已经很简洁了,也许可以考虑如何缓存供货关系,不要一直查 DB。等数据量大到一定程度,你应该会选择按照 [供货商 ID] 分库分表了。

  • 我的透明创业实验 at 2019年05月20日

    程序员的正确姿势

  • 如何看待 996.ICU at 2019年04月28日

    996.icu 是社会对劳动密集型、可替代性强、年龄敏感、壁垒不高等等强应用型职业面临的严峻挑战的一种善意提醒。

    这种职业状态是很大一部分程序员职业发展可能的最终状态。

    世上大部分抗议都是效果不大的,只有尽可能想办法避开。

    以上说给我自己听的。

  • 两千多个挺正常的,你 nginx 和 puma 是跑在同一台机器上的,nginx 每次转发请求实际上都会创建新的 TCP 连接,连接没有被复用后面就 timewait 了。如果并发量高的话确实会出问题,upstream 就会连不上,sourceIP:Port -> DesIp:Port 耗尽了。

    一般有几个解决方案:

    • 把可用随机端口调大 net.ipv4.ip_local_port_range
    • 后端多搞几个 upstream
    • Nginx 在 upstream 中用长连接
    • 开 tcp_tw_reuse 和时间戳 并且限制 timewait 的总数量,当触发上限时就会剔除旧的
    • nginx 和 puma 在同一台机器上时可以用 unix socket 避开 tcp 协议栈
  • 关于散列表的一些思考 at 2019年03月13日

    棒!

    可以继续解释一下哈希如何存放不同类型的 key 和 value

  • 18 年三月份刚来上海面的第一家就是薄荷,宝贵的经历啊。

    由于当时经验不足,也没有” 证据 “证明自己是谁 (底气很虚),然后被问了两个简单的工程应用问题,仓皇之下答的一塌糊涂。回去了解了一下就是简单的乐观锁应用和 feed 流的知识,听到 vincent 叹息了声” 时间过的好快 “(面试时),当时就意识到没戏了。面试前准备了许久了数据结构/算法/redis 底层/tcp/LB 等知识完全没被问到,当时也不太懂要引导面试官往自己熟悉的方向走,或者争取机会在其他方面证明自己。

    vincent 当时出于礼貌 (自己感觉当时该立即埋头出门的),带我逛了一下薄荷,个人感觉薄荷还是不错的!

    在经历了一系列类似的场景后,让我蓄积了大量动力去尝试写技术文章。认识到构建个人对外的沟通界面真是太重要了。

    还在路上的菜鸟在此表示感谢!

  • 从上帝视角看微服务 at 2019年03月05日

    描述系统混乱程度的经典概念。维基百科

  • 什么是 RPC? at 2019年01月31日

    角色扮演游戏? 作为游戏盲又了解了一个概念···

  • 有个简单的方案:

    功能有这几个重点:

    • 竞拍,更新状态 (价格/截止时间等)
    • 到点后自动结束竞拍

    有两个对象:(名字随意取的)

    • 被竞拍物 (Goods)
    • 竞拍物状态 (GoodsStatus)

    每次有人出更高的价格,其实就是在更新 GoodsStatus,可以为每次出价都持久化一条数据,核心字段是价格截止时间竞拍人,并将 Goods 对应到最新的 GoodsStatus。

    每次竞拍都往 sidekiq 中插入一条定时任务,任务执行时检查当前 GoodsStatus 是否是最新的,不是的话直接退出。如果是最新的话就结束竞拍。

    用 sidekiq 的时候需要注意的是,sidekiq 取定时任务的时间点并不精准,可能会有数秒的误差 (可以配置),sidekiq 里面的任务本质上是一个个被取出处理的,要保证 sidekiq 的处理能力足够强,避免当竞拍任务过多时,任务延迟过多。

    竞拍应该还有个大盘,大盘在” 轮询 “的时候,也可以检查时间点,做结束竞拍的动作。

  • 文章不错,聊一点个人拙见。

    更喜欢将本文标题理解为: 开发者如何变得更加优秀、能创造更大的价值?

    之所以这样理解,是因为很多人像我一样现在只是一个普通的开发者,但我相信很多年后,随着不断地积累,我们这帮人会慢慢从开发者的角色逐渐分化,变成一个复杂的综合体,也只有这样,才能够真正地实现更大的价值创造,分化的方向大概是:

    • 拥有产品经理的能力
    • 拥有项目经理的能力
    • 拥有 leader 的能力 (判断力、打造团队等)
    • 拥有开发者的能力
    • 拥有搞定人的能力
    • ···

    多年后,从开发大军中脱颖而出的人,都会拥有上面这些方向的素质,成为一个复合体。放眼望去,在大的团队或项目中产生核心价值的人,都是这种复合体。 大部分节点上的螺丝钉都只是螺丝钉而已,当然这些螺丝钉的价值总和还是会非常大的,只不过均分到人头上就不见得了。

    不过,除了上面的分化,部分在技术圈备受崇敬的人还有另一种发展方向,就是成为能搞定高难度技术点的精英,他们会在相对单纯的技术环境下创造价值。 不过大部分这种人才其实也具备产品经理和项目经理的能力。

    能吃透行业,在某个方向上有深耕的复合体,具有很大的单点价值。

    Matz 是开发者吗? 不是,他是一名拥有开发能力的和项目管理能力的产品经理。他的核心价值在于设计了 Ruby 这款解放程序员的产品,并在带领开发者迭代 ruby 这个项目。

    马化腾是开发者吗? 不是,他早期是拥有开发能力的产品经理,现在应该算是懂技术、产品、项目管理、市场···的 leader。

    ···

    一个人只有两只手,一天能写的代码量太有限,高价值的代码更有限。何况岁数变大,体能还在下降····

  • 说实话,这个代码我不能快速看懂。“冗长” 点的代码更容易理解吧。 文章里代码写的糙,将就点看😂

  • 从上帝视角看微服务 at 2019年01月02日

    技术的应用肯定是有很大价值的,从有些角度来看技术的应用比其本身更有价值。不过这个价值是大部分是由企业家/产品经理来引导,” 架构师 “来选型做抽象,剩下的那些价值就不大了,可替代性太强了,很多是框架下简单的重复而已。

  • 从上帝视角看微服务 at 2019年01月02日

    移动互联网催生了微服务这类的效率改善措施,业界有很非常多好的正面的有指导意义的微服务例子。有人浑水摸鱼,或者胡搞一通,以某项技术来获取利益,这也挺正常,每项技术出来都会被炒,不过这是人或做事方式的问题,和技术本身关系不大。

    ServiceMesh 由谁来做,也许对大多数码农来说没有区别。把大多数显得牛逼的项目中的开源组件拿掉,可以发现很多码农的核心价值趋近于零。不过这些牛逼的开源组件确实是部分码农搞出来的,总有人在做有挑战的事情。