安全公司 Mend 在 2022 年前九个月发现并添加到其漏洞数据库中的开源漏洞数量比 2021 年增加了 33%，这反映了已发布的开源软件包数量的增长。该报告从 2022 年 1 月到 2022 年 9 月对大约 1,000 家北美公司进行了代表性抽样，结果显示已知漏洞中只有 13% 得到了修复，
# 背景 公司之前部门拆分，但一些服务并没有拆分清楚。其中一个老服务，两个部门都在用，现在为了避免互相影响，决定克隆该服务。克隆就要克隆全套，当然也包括数据库，我们这个老服务，用的oracle，所以，就涉及到从旧的oracle中导出数据，然后再导入到另一套新的oracle实例中。 届时在线上肯定是要
前言 公众号每月定期推广和分享的C#/.NET/.NET Core优秀项目和框架（公众号每周至少推荐两个优秀的项目和框架当然节假日除外），公众号推文有项目和框架的介绍、功能特点以及部分截图等（打不开或者打开GitHub很慢的同学可以优先查看公众号推文，文末一定会附带项目和框架源码地址）。注意：排名不
1024，祝每个程序员小哥哥小姐姐节日快乐。 因为在研发效能部门，我支持过几次 1024 程序员节的活动，所以经常有朋友问我1024 程序员节怎么做，本篇就是简单介绍下我的思路，希望对你有用。 1024程序员节的由来 俄罗斯把每年第256(=2^8）天，即平年9月13日或闰年9月12日定为国际程序员
今天一个小伙伴问我，如何「快速提升」一个团队的软件开发成熟度？我犯难了。我个人理解一个团队的软件开发成熟度涉及的东西很多，但最简单最直接的方法就是发钱涨工资，可是估计很多公司不愿意，那就只有扣了。 快速提升的目标 短期制度解决 如果想短期快速提升，那就直接梳理好最关键点，制定规章制度，然后通过奖惩制
最近某位大神在推特上发了一个帖子，结果引来了国内众多卖课机构、培训机构的狂欢，开始贩卖焦虑，其实「平台工程」也不是什么特别高深莫测的东西。闲得无聊，把这位大神的几个帖子薅了下来，你看过之后就会觉得没啥，都是熟悉的东西。 Sid Palas & 平台工程 这位大神的名字叫 Sid Palas，一位专门
之前的一篇文章《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意，有的小伙伴非常不同意，我觉得这都是非常正常的反馈，话不说不透，理不辩不明，我还是特别希望能和大家一起把这个问题弄明白。这篇文章就是那篇文章的后续，本文主要讨论开源社区、开源
大数据技术的发展是一个非常典型的技术工程的发展过程，荣辛通过对于谷歌经典论文的盘点，希望可以帮助工程师们看到技术的探索、选择过程，以及最终历史告诉我们什么是正确的选择。 何为大数据 “大数据”这个名字流行起来到现在，差不多已经有十年时间了。在这十年里，不同的人都按照自己的需要给大数据编出了自己的解释
框架类是否适合企业内源？ 框架类都由公司早期来的一些大佬们负责（相当于技术委员会），更新频率非常低。给框架类提MR的人，多数本身就在技术委员会。 如果公司的人员众多，类似BAT级别，几万人使用的框架，大家一起添砖加瓦也许是合适的，尤其适合那些公司本来已经开源到开源社区的框架。但做之前肯定有大量的学习
2022年12月18日上午，阿里云发布《阿里云香港可用区C某机房设备异常》公告。“阿里云监控发现香港地域某机房设备异常，影响香港地域可用区C的云服务器ECS、云数据库PolarDB等云产品使用，阿里云工程师已在紧急处理中。” 在这个寒冷的冬天，一个炸雷给业界惊起了一个大波浪。很多人不解的是说好的高可
三年疫情改变了人们的生活，也改变了行业的趋势。三年大疫，让一路疾驰的科技互联网急踩刹车，减速换挡，很多企业从高歌猛进到黯然失色，甚至是伤感落幕。活着的公司也都纷纷砍一刀。 2022年1月，百度，AIG、MEG多业务线精简，约10-15%，涉及基层，中层和高层 2022年2月，滴滴，网络车、货运、中台
专注 300 页之内的经典书籍推荐 研发效能涉及的知识很多，从大的方向去划分包括制度、组织、平台、运营等；单从软件研发的角度去看也包括很多，包括最底层的软工认知、实践，到团队管理和组织、敏捷研发，项目管理、源码管理、发布管理、可观测性，到产品的运营和反馈。 现在很多公司已经组建了或者正在组建研发效能
职责与自驱 产品经理是要保证做正确的事；项目经理则是保证正确地做事；FTO 既要保证做正确的事，也要保证正确地做事，还要保证能拿到结果，且对结果负责。 能做事的专业人才不缺，但是既有专业知识和技能还能自驱的人很少。自驱对于小团队来说尤其的宝贵。 心里要有火，眼里要有光 找方向、建团队、不用告诉他要做
想要做好业务，老板们除了要梳理好公司级别的业务目标，公司的组织架构，还要搭个有产出的班子，也就是找负责人、建团队，让组织架构充实起来。搭班子最重要的就是把负责人找到，就是团队1号位的人。本文主要讲团队负责人的主要作用，怎么才能找到，不同背景的优劣势，以及各方面的要求。 研发效能团队1号位 「火车跑得
有人说研发效能是老板工程。不是的，研发效能不是老板工程，它不直接服务于老板(虽然老板可能看一些报表)，反而是服务于广大产研运（产品+研发+质量+运维）的同学，所以有的公司也把研发效能叫做基础中台，平台工程，开发者服务团队，或者叫开发者服务平台。做好研发效能，做好开发者中台，就容易把公司的各种中后台能
现在很多公司都在做或者计划做研发效能，也知道研发效能工作很重要，能提高产研运同学的协同效率，提高员工的工作效率和质量，提高业务交付效率和交付质量，但是价值有多大？效率又有多高呢？因为不容易说清楚，所以经常碰到一些质疑和灵魂拷问。 如何衡量研发效能的效果？ 如何衡量研发效能的作用？ 如何说清楚研发效能
国内公司普遍不注重基础设施建设，这也是可以理解的。吃饭都吃不饱，就别提什么荤素搭配，两菜一汤了。但也不能全说是这样，还是有很多公司投入大量的人力物力去做好公司的基建，比如很多阿里和美团的小伙伴对公司的基建还是很认可的。 为什么工程师都很在意公司的基建 有人说再好的磨盘也只是提升了驴拉磨的效率，便宜了
之所以写这篇是因为有朋友私下让我完善下基建建设的标准和四个阶梯划分，然后让我一定要把腾讯和百度加到基建建设的排名中(看热闹不嫌事大）。 基建infra建设四个考察维度 1)工具链完整性：该有的工具是否都有了 2)功能完备性和易用性：工具该具备的功能是否都有了，是否容易使用 3)支持和服务：是否有人持
我特别反感那些不顾公司现状一上来就想要做研发效能度量的人，尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量，就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下，公司想要做好研发效能度量也有标准的三步：长时间对研发效能
之前写过一篇文章《devops｜中小公司不要做研发效能度量》，主要是从基础设施方向考虑，因为很多条件都不具备，贸然高投入去做研发效能度量可能达不到我们的预期效果，给出的建议是先做好当下打好基础。今天想到一个好例子，可以类比下。 两个人小家庭 1）人少 2）收入清晰 3）支出清晰，买了什么东西，花了多
