面向对象编程，为什么这么多人讨厌它？ - 读书笔记
https://mp.weixin.qq.com/s/yZIk5xuDYPUgr38i-0_ESA?utm_source=pocket_mylist
Posts
DevOps平台的产品规划思考 - 读书笔记
https://www.toutiao.com/a7043600901508088334/?log_from=94eb1c45d0dc5_1640052448731&wid=1640288269363
缓存使用小技巧 -- 读书笔记
https://mp.weixin.qq.com/s/9Lmr9DM-0YrdcaZZKGGu1A 缓存使用小技巧： （1）服务与服务之间 不要通过缓存传递数据； （2）如果缓存挂掉，可能导致 雪崩 ，此时要做 高可用缓存 ，或者 水平切分； （3）调用方不宜再单独使用缓存 存储服务底层的数据，容易出现数据不一致，以及反向依赖； （4）不同服务， 缓存实例要做垂直拆分；
运维事件管理 和 文档 - 读书笔记
https://mp.weixin.qq.com/s/6M6ZQrkzmg2h0ez7mFpKWQ ITIL 为 ITSM 提供了专业术语和流程指导，告诉我们应该怎么去做 IT 服务，而 ITSM 是落地的 IT 服务，不停的在流程中被使用。 IT 服务管理的难点就在于管理的无序和被动，无法透明化或可视化，技术人员的服务意识差，效率低且 IT 人员的成本高；IT 服务的风险也是很大的， ITIL 中 IT 的服务管理包含 服务台管理、 事件管理、 问题管理、 问题管理的目的是防止问题和因问题而造成事故（Incident）的发生，以最大程度减小 反复出现事故 （recurring incident）的发生，以此最大程度减小无法避免事故的负面影响。 信息技术基础架构库 （ITIL）有如下定义：问题是 事故 的原因。 变更管理、 配置管理、 发布管理、 服务级别管理等。 https://mp.weixin.qq.com/s/iwyHJCuno2zrC9qetflcVA
负载均衡 - 读书笔记
https://mp.weixin.qq.com/s/ZZXYhG_UUecESBDmp8jqPg 四层负载均衡 七层负载均衡 URL解析 ❌ ✅ 擅长 DNS域名轮流解析 应用层负载调度 客户管调度 原理 通过报文里面目标地址来调度 通过报文中真正有意义的内容 a) 通过修改IP方式 SNAT -> DNAT NAT: Network Address Translation b) 通过修改目标MAC (Direct Routing) LVS 四层LB Nginx 七层LB HAProxy， 四层和七层
如何优雅的关闭容器，看这一篇就够了
https://mp.weixin.qq.com/s/OojCtlC1HZkc5X9XYDecNg 不管你 Dockerfile 用其中哪个(ENTRYPOINT, CMD) 指令，两个指令都推荐使用 exec 格式，而不是 shell 格式。原因就是因为使用 shell 格式之后，程序会以 /bin/sh -c 的子命令启动，并且 shell 格式下不会传递任何信号给程序。这也就导致，在 docker stop 容器的时候，以这种格式运行的程序捕捉不到发送的信号，也就谈不上优雅的关闭了。 docker stop 停掉容器的时候，默认会发送一个 SIGTERM 的信号，默认 10s 后容器没有停止的话，就 SIGKILL 强制停止容器。
链路分析 K.O “五大经典问题” - 读书笔记
https://mp.weixin.qq.com/s/9KX04mmLNQbKZt-iQYk7qg 【流量不均】负载均衡配置错误，导致大量请求打到少量机器，造成“热点”影响服务可用性，怎么办？ 通过链路分析按 IP 分组统计链路数据，快速了解调用请求分布在哪些机器上，特别是问题发生前后的流量分布变化，如果大量请求突然集中在一台或少量机器，很可能是流量不均导致的热点问题。再结合问题发生点的变更事件，快速定位造成故障的错误变更，及时回滚。 【单机故障】网卡损坏/CPU 超卖/磁盘打满等单机故障，导致部分请求失败或超时，如何排查？ 通过链路分析先筛选出异常或超时请求，根据宿主机 IP 或容器 IP 进行聚合分析，快速判断是否存在单机故障。如果异常请求集中在单台机器，可以尝试替换机器进行快速恢复，或者排查该机器的各项系统参数： 【慢接口治理】如何快速梳理慢接口列表，解决性能瓶颈？ 找到慢接口后，可以结合相关的调用链、方法栈和线程池等数据定位慢调用根因，常见原因包括以下几类： 数据库/微服务连接池过小， 大量请求处于获取连接状态，可以调大连接池最大线程数解决。 N+1 问题， 比如一次外部请求内部调用了上百次的数据库调用，可以将碎片化的请求进行合并，降低网络传输耗时。 单次请求数据过大， 导致网络传输和反序列化时间过长且容易导致 FGC。可以将全量查询改为分页查询，避免一次请求过多数据。 日志框架“热锁”， 可以将日志同步输出改为异步输出。 【业务流量统计】如何分析重保客户/渠道的流量变化和服务质量 可以使用链路分析的自定义 Attributes 过滤和统计实现低成本的业务链路分析。 【灰度发布监控】500台机器分10批发布，如何在第一批灰度发布后，就能快速判断是否有异常？ 变更三板斧“可灰度、可监控、可回滚”，是保障线上稳定性的重要准则。其中，分批次灰度变更是降低线上风险，控制爆炸半径的关键手段。一旦发现灰度批次的服务状态异常，应及时进行回滚，而不是继续发布。 不同机器流量进行版本打标 {"attributes.version": "v1.0.x"} ，通过链路分析对attributes.version 进行分组统计，可以清晰的区分发布前后或不同版本的流量变化和服务质量。不会出现灰度批次异常被全局监控掩盖的情况。 基于链路明细数据进
1-2-1 的一些建议
- 交流听说的一些org/大team的动（八）向（卦）以及对具体工作的影响，有时是可能潜在的新项目，有时可能是老板听说xx大佬入职了建议我去聊一聊，etc - 我自己工作上的一些需求，具体的比如事情太多了需要老板帮忙offload，跟别组撕逼希望老板支持，抽象的比如long term想转去做xx方向希望得到这方面的support - 对team里其他人的反馈，比如xx同事特别给力强烈地赞美一下，或者xx同事要把我逼疯了问老板有没有什么建议 - 和老板相互给工作方式上的feedback和希望有哪些actionable item，这个需要有一定的trust以后才比较好讲。 - career path/performance：除了公司规定的perf conversation，一般都是结合上面几条偶尔老板画个具体的饼。以前也碰到过有mgr就是空讲career，但是我个人觉得太虚的饼其实讲了也没什么意义，尤其如果每次都讲的话。 聊兴趣爱好/生活的。 管理双方的期望，他希望你做什么， 你有什么想sell的， 都需要长期的follow-up才能有很好的engagement。 前10分钟扯闲天，中间10分钟汇报一下上周干了什么这周想干什么，后十分钟问他有没有什么想要问我的问题/heads up/大方向的计划。 至于职业发展那些，可以聊闲天section随便聊两句，或者每两个月专门拿出来一次one on one专门聊这个就足够了。 如果你被别的组block住了，可以找老板让他出头。 https://instant.1point3acres.com/thread/671245 https://www.1point3acres.com/bbs/thread-458288-1-1.html http://www.woshipm.com/zhichang/2916673.html https://www.sohu.com/a/433275457_440524 - 重要的项目进度： - 项目idea： - Career growth： - 提出对组里的意见： - 感谢老板： - Politely complain： - 给同事的feedback：
Functional Manager vs Chapter Lead
https://project-management.fandom.com/wiki/Strong_matrix https://www.jobhero.com/job-description/examples/administrative/functional-manager Allocate Unit Resources Functional managers make day-to-day decisions regarding unit resources, including finances and staff delegation, to effectively meet expectations and complete projects. Functional managers examine projects in the pipeline and assess the needs of the project managers responsible for completing those projects, then determine how to best allocate the unit’s resources to complete projects on time and according to budget. Maintain Master Schedules Because business units often have many projects occurring at once, the functional manager manages and maintains a master schedule to ensure that work is completed on time. This schedule may include due dates for specific projects and deliverables as well as personnel-specific schedules, which can be especially important if staff members work on multiple project teams. Manage Project Bud
Redis分布式锁使用不当，酿成一个重大事故 读书笔记
https://mp.weixin.qq.com/s/SuORU3Ztt2-RGPpWXh7LTg 分布式锁 https://zhuanlan.zhihu.com/p/42056183
DNS 读书笔记
https://mp.weixin.qq.com/s/-siIQ9K3OhiqoganFStDig?utm_source=pocket_mylist DNS解决了单机上面hosts 文件无法维护的情况 Host文件是第一个DNS，可以通过再Host文件里面强行把一个ip 指向另外一个 网址
数据库（MYSQL）运维要点 - 读书笔记
https://cloud.tencent.com/developer/article/1579285 数据库复制技术 异步复制 - 应用 发起更新 --> Master 执行操作 -> Master响应应用 -> Master 向Slave 复制 半同步复制 应用 发起更新 --> Master 执行操作 -> Master 向Slave 复制 -> slave接收数据 -> Slave写到Relay Log里面，但不执行 -> Slave 响应Master -> Master响应应用 同步复制 应用 发起更新 --> Master 执行操作 -> Master 向Slave 复制 -> slave接收数据 -> Slave执行更新 -> Slave 响应Master -> Master响应应用 至少两个Slave，来保证Slave高可用 高可用 binlog 日志用于记录所有更改数据的语句，俗称二进制日志，主要用于复制和即时点恢复。主从复制也是依赖于 binlog 的。类似于 Oracle 的 archivelog，Mongodb的oplog，所有和写有关或者可能有关的语句，都会记录在 binlog 文件中。 慢查询 慢查询就是执行数据库查询时消耗时间比较大的 SQL 语句。MySQL CPU 利用率过高，大部分原因与低效 SQL 有关系，通过优化低效 SQL 基本可以解决大部分问题。
不要再docker里面跑数据库 - 读书笔记
https://www.toutiao.com/i6675622107390411276/ 数据安全不高 不要将数据储存在容器中，这也是 Docker 官方容器使用技巧中的一条。容器随时可以停止、或者删除。 但是容器的 Volumes 设计是围绕 Union FS 镜像层提供持久存储，数据安全缺乏保证。如果容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。 性能不高 关系型数据库，对 IO 要求较高。当一台物理机跑多个时，IO 就会累加，导致 IO 瓶颈 解决办法 数据库程序与数据分离 数据库程序与数据需要进行分离，将数据存放到共享存储，程序放到容器里。如果容器有异常或 MySQL 服务异常，自动启动一个全新的容器。另外，建议不要把数据存放到宿主机里， 跑轻量级或分布式数据库 Docker 里部署轻量级或分布式数据库，Docker 本身就推荐服务挂掉，自动启动新容器，而不是继续重启容器服务。 状态问题 Docker 快速扩展的一个重要特征就是无状态，具有数据状态的都不适合直接放在 Docker 里面，如果 Docker 中安装数据库，存储服务需要单独提供。 资源隔离问题 Docker 是利用 Cgroup 实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。 应用场景 对数据丢失不敏感的业务（例如用户搜索商品）就可以数据化，利用数据库分片来来增加实例数，从而增加吞吐量。 Docker 适合跑轻量级或分布式数据库，当 Docker 服务挂掉，会自动启动新容器，而不是继续重启容器服务。 数据库利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点，也是可以进行容器化的。