最狗屎的问题，我们也有类似的：
A 项目代码，仅供内部使用（实际上也算是客户），beta 和 lastest 标准化的版本均在其发布，项目主体团队自己消化，如果不是公司内部的，找个标杆的客户项目为主干来开发。
B 项目代码，基于 A 的 V1.0.0 版本，因对外客户要求，需要定制开发各类东西，页面样式改版，认证和组织架构变更等等，一般交给交付团队来实现。
C 项目代码，基于 B 的 V1.0.5 版本的某几个阉割后的微服务模块，也是一通改造定制，客户看中了 A 项目的代码，但因为 A 的代码早就不断更迭很多次，要同步上来就得 rebase 整理原来多次变更过的所需模块微服务代码。而前端代码则需要定制化开发，一般交给交付团队来做。
...

过程的东西，如版本发布，需要严格一点的流程管理，每次发布版本都要经过各角色评审，才允许放入制品库，不允许私自定义版本，所有版本需要控制输出。

如果团队人数>10 ，那么就不要一个团队干多个项目的交付实施的活，牵扯过多很容易出问题。分配几个小组（人数>3 ）分别负责不同的项目（ 3<n<5 ），主力核心则至少保证>5 ，因为个项目有些需求必定要核心成员来对交付工作做决策，并不是简单的做出来就不管，另外找外包或者专项招交付岗位的人来负责 1-N 个项目的交付开发工作

如果团队人数<10 ，原则上，每个人承担负责项目不要超过 3 个，不然离职交接和沟通就等着炸吧，项目多就多招人

项目和人多了真就不是技术规范能解决的问题了，必须要考虑流程和推进的工作保障，哪些项目由谁管理，怎么管。可以考虑从如何对人员角色划分和放权管理去下手。

另一条路就是售前和交付团队的有效沟通，让客户自愿吃下这坨，然后还说不出啥，觉得自己就是弱，你们做出来的就是牛皮，需求不满足那是自己还不会用你们的系统，做不到的东西是根本不存在这样的需求。

最狗屎的问题，

需求评审，大家一起给所有需求实现难度以 1.0-5.0 数值打分，谁最后接手难度大的并且完成，那么即可获得分数，统计一下数量和分数分布，用于辅助客观评价成员活动

如果做过一些优化，技术性能数据能满足业务，那么长期保持说明资源利用率被高效利用了，而很多研发根本不管运维成本，很多机器资源都是闲置浪费的。
如果担心有问题，至少保证服务不是单点，做多节点水平扩展高可用，最建议上云（基于 kvm/container 技术），根据负载状态动态伸缩资源

目前 BUG 有点多，但并不影响生产使用

版本 Windows 11 专业版 Insider Preview
版本 Dev
操作系统版本 22463.1000
体验 Windows Feature Experience Pack 1000.22463.1000.0

真搞笑，一个运维连传话筒都做不了，每天审批工单就够整活了，别说在庞大机群规模底下做运维。感觉就是打广告拿需求的。
你们充其量也就一个做监控平台的，难道也想把整个 IaaS 所有管理层面的工作都给抹平了，你真给想屁吃，先追齐深信服的云解决方案再说吧，最多就上层运维平台的一个子系统，各种虚拟化计算、存储、网络管理、流程引擎、服务编排、迁移和灾难恢复、计费治理等基础资源纳管能力都没有，谈什么服务器管理，真就当服务器管理就开关机 /遇障重启呗
而想要靠一个平台系统来解决这些问题几乎是不可能的，功能能齐备就很不容易了，更何况各公司架构和技术栈千奇百态，光采购适配就有的搞，一般大点公司都是自研的，外采管理压根就不用想，出了问题都是自己的命，哪敢交给别人
一个人，如果没有完整成熟且高度自动化的基础平台支撑各项业务，那么可以在那等死了

在线 dump 内存，解析 coredump 文件，用 MAT 工具作为示例效果会比较不错

直接拿现金，大保健两次，芜湖起飞~~

想太多，客服大多数公司都是外包出去的，而且能力水平普遍不行，专业点也就客服经理了，不满意也可以投诉，还不如去狗东买

用 ThrottleStop 给 CPU 降压、锁睿频保证你稳定频率，并提升功耗比，从而降低温度。记得设置后要做好压测，不然体质不好的 CPU 会导致蓝屏

卡顿一般是 CPU 热保护或者你有 OEM 厂商的电源管理软件帮你自动降频了，这个只能自己排除下：
1. 散热问题，CPU 温度建议稳定在 85°C 以下、硬盘 60°C 以下会比较好。平时可自动调整风扇转速，自己去 google xxxfancontrol 工具，比如 nbfc，大多数的品牌的都有，但不一定保证 profile 有效，可能需要自己去调整。自己用 AIDA64 的系统稳定性测试压测一下，很容易复现问题
2. 卸载全部 OEM 提供的电源管理或优化驱动，只保留基本的触摸板驱动。确保当前系统电源计划是高性能。

gtx1080 2k avg=25fps

确实有对每一帧的图片计算压缩，那么必然损失一些像素信息，尤其是运动画面会有不稳定的情况，码率不完全恒定，具体自己去看 ffmpeg 的设置：crf （限制码率） cqp （固定质量） abr(平均码率)

1. 只考虑高可用，为了方便后续扩展，建议用 keepalived 作 vip，这样程序可以只需要指定唯一 IP 地址即可，而不用关心后边数据库的运维动作。
2. 同时考虑负载均衡，那么再上个 haproxy 来做 4 层(TCP)代理
3. 可以考虑用 dns 记录，也是比较简单的方式
3.1 dns 服务器可以用 consul 来做，同时来做服务发现自动去注册数据库服务，并做健康检查。有个缺点是可能需要其它要访问数据库的服务需要配合 dnsmasq 来做本地 hosts 和 dns 解析服务器管理

丢一些具体场景的难题，让他尝试解决。主要考验沟通能力、思维活跃程度、知识面深度，需要让他自己跟你主动说问题和方案，你可以限定一些条件来让他回答框架之内的内容防止话题过大。
对于自己不懂的直接说自己不了解，别装 B，请教他让你也能了解相关领域的应用实践内容，既然是有经验的，那么讲出来的东西肯定是有一定逻辑和组织的，否则只是了解写术语而已，没有真的应用或接触过，大多数都只会说一些唬人的，一问真正用到哪，怎么用的，就讲不出来了，只会回答说在某些资料上有看过。但这也是一种能力，不一定所有说出来的都必须知道详细的原理，但凡有记忆点，那么解决问题的时候能够比不了解的人多不少手段，前提还是要有一定理解，而不是用了 xxx，需要知道为什么用，有什么作用。

主要区别看人，两者只是干活的范畴不一样，只是有的人会更适合 /习惯一些思考方法……
程序员更偏向于逻辑思考，这是程序员的思维优势和习惯，而恰好人会自然地倾向于自己熟悉或习惯的事情，但如果思维足够清晰，能够跳脱具体干活的层次，不过分纠结自己过往的技术经验判定，而是以真实的用户为角度去思考这个东西该如何使用，到底为自身或组织带来多少的价值，那么就相对能够更靠谱的给出产品设计，至少产品功能逻辑漏洞不会很大，毕竟是有系统层次模型设计的积累

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-python3.html
看这个对各个语言的 benchmark 吧

根本不用比好吧，而且 go 也并不是在高级语言中性能最强的，甚至有些还比不上 Java，python 也可以用 native+vm 方式（如 Cython ）来提升性能敏感模块的处理速度，混合用不就完了