{"id":13632813,"url":"https://github.com/liquanzhou/ops_doc","last_synced_at":"2025-05-14T13:09:32.393Z","repository":{"id":32680185,"uuid":"36268954","full_name":"liquanzhou/ops_doc","owner":"liquanzhou","description":"运维简洁实用手册","archived":false,"fork":false,"pushed_at":"2024-12-12T03:00:07.000Z","size":7824,"stargazers_count":1236,"open_issues_count":3,"forks_count":868,"subscribers_count":116,"default_branch":"master","last_synced_at":"2025-04-11T18:21:37.748Z","etag":null,"topics":["ops","python","shell","sre"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/liquanzhou.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-05-26T03:14:34.000Z","updated_at":"2025-04-09T16:02:10.000Z","dependencies_parsed_at":"2024-01-14T07:14:46.168Z","dependency_job_id":"92a47689-dcbe-42ec-9811-745ee431dcf9","html_url":"https://github.com/liquanzhou/ops_doc","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/liquanzhou%2Fops_doc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/liquanzhou%2Fops_doc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/liquanzhou%2Fops_doc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/liquanzhou%2Fops_doc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/liquanzhou","download_url":"https://codeload.github.com/liquanzhou/ops_doc/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254149976,"owners_count":22022852,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ops","python","shell","sre"],"created_at":"2024-08-01T22:03:16.775Z","updated_at":"2025-05-14T13:09:27.382Z","avatar_url":"https://github.com/liquanzhou.png","language":"Shell","funding_links":[],"categories":["Shell"],"sub_categories":[],"readme":"## ops_doc\n\n  文档制作: 雪松\n  \n  更新日期: 2016-04-28\n  \n  本文档手册希望可以达到通俗易懂，方便运维人员使用，错误在所难免，还望指正！\n\n  github更新下载地址:  https://github.com/liquanzhou/ops_doc\n  \n  请勿删除信息，转载请说明出处，抵制不道德行为\n  \n  \n  \n  \n  \n  \n### 一.总是听到有说: \n  \n#### 1.运维累，背锅，薪资低?\n\n运维没做好，没有核心技能，肯定是累且背锅，薪资涨不上去。各行各业皆是如此，最底层都是一滩烂泥，不仅仅是运维行业。小事(运维处理个磁盘，处理个内存报警)其实就能体现出来能力. 太多运维都是处理表面问题，根本不去真正了解需求，也不去思考解决办法，不用心去把事情做漂亮，成长也基本止步，指望这类人去搞点创新，解决点难题，基本不可能，反过来想这种人怎么可能高工资?\n做任何行业都一样，重要的是思考: 怎么差异化，怎么脱颖而出，做出与众不同，怎么做到核心精英.\n\n#### 2.运维开发的自动化取代运维?\n\n运维开发只是运维的一个技能分支，不需要神话运维开发。大多是培训招生鼓吹，运维开发淘汰运维。只做运维开发，不了解运维业务，做的系统平台怎么可能好用？\n不了解业务，平台实现无法统一标准，统一流程。\n\n#### 3.云平台取代运维?\n\n云商资源是工具，业务问题是云商无法解决干预的，需要专业运维人员使用拼接。\n\n#### 4.人工智能取代运维?\n\n人工智能类似GPT取代运维更是不可能，只会更好的帮助运维工作。高级运维要在架构能力，主导能力，灵活运用，解决各种复杂难题，并不是人工智能直接给出的建议就能解决。\n  \n\n\n### 二.做好本职工作:\n\n坚持本心，切勿浮躁，避免被他人干扰。\n\n不了解运维痛点，不解决业务难题，无论运维，SRE，运维开发都是做不好的。\n\n干活前多统计，多准备，多思考规避问题，多考虑简化方案。干的时候先挑大块的标准化的方式搞\n\n见过运维技术好，搭建各种服务效率，各种参数都知道，可唯独没有任何标准化思维，导致工作累，业务又频繁故障。\n\n运维岗位比其他技术岗位更了解技术架构全链路，很多开发和架构解决不了的问题只能依靠运维。\n\n做运维部门核心技术人员，核心技术能力才能让自己不可替代。不要区分运维和运维开发，两方面能力都重要。\n\n\n \n \n\n\n### 三.针对运维岗位的一点经验看法:\n  \n##### 做好技术，技术到了一定程度，多考虑业务。核心是用技术解决业务上的难题，想办法从根本原因解决问题。不能只解决表面问题。少一些花里胡哨的技术和流程。\n##### 多花心思考虑实用性，稳定性，运维可协同维护，开发的用户体验等。\n##### 多梳理业务，没什么解决不了的难题。\n##### 多主导业务，技术和能力才能提高质变。\n##### 监控(三层兜底监控和多维度的监控)和发布(打包，发布，服务注册，平滑上线，流量接入，自动扩容)是最核心重要的工作，需要反复打磨，简单好用，好协同。\n##### 工作标准要高，不能只搞表面，才能不被其他部门骂。\n\n\n统一业务标准化: 环境一致，数据一致，流程一致。最后才是自动化的实现。\n  \n业务可观测: 故障第一时间可以报警，链路可追踪，监控图表可事后分析。减少无用信息，快捷有效。\n  \n业务稳定性: 稳定是核心标准，处理故障后，多分析原因始末，多和业务方和架构师探讨交流，积累架构经验。\n  \n  \n  \n### 四.针对k8s使用的一点经验看法:\n\n\n好多公司运维部门都是积极使用k8s，但没有规划的使用又会引起好多不易维护的难点痛点:\n\n\n1.缺少自动化，导致繁重的人肉维护大量yaml文件\n\n\n如果可以，k8s内部的yaml尽量规避任何人肉改动，全部发布系统标准化生成(deployment，service，hpa，inrgess，vs等等全部统一与模板一致).规避复杂的7层路由策略在k8s中做.尽可能对外入口统一，k8s流量接入与deployment一一对应，就可以实现k8s内部全部标准化自动生成\n\n\n2.无法统一注册中心，每组k8s有各自的etcd注册，两组k8s中服务互联就会有麻烦，开发可能更喜欢服务框架依赖的各自注册发现方式.导致流量接入混乱.流量平滑，维护复杂，多语言服务互联障碍.\n\n\n这个情况，要看实际业务场景，多与开发架构师沟通方案，如何推动统一注册发现机制，让开发互调流量和运维的流量接入统一\n\n\n\n\n### 五.新工作环境梳理工作思路:\n\n\n1.优先解决棘手的业务稳定问题\n\n\n2.多维度监控，确保第一时间发现问题，定位问题根因\n\n\n3.多与架构交流，沟通稳定性解决方案\n\n\n4.统一打包和发布，定好标准的全流程，拒绝开发各异的方式，但还能支持开发多种合理的需求，有足够的扩展能力\n\n\n5.提升自动化工作范围\n\n\n6.成本控制\n\n\n7.精准报警，清理无用大量报警\n\n\n8.清理无用5xx错误，程序error干扰\n\n\n\n### 六.中小公司做到如下标准,就能解决大部分运维痛点:\n\n##### 运维标准:\n\n1.服务全部标准化,统一打包和部署方式\n\n2.监控图精准易用\n\n3.监控报警灵敏,避免重复检查次数,触发即报警\n\n4.报警维度健全\n\n5.尽可能自动化\n\n6.自动扩容(需要服务上下线平滑)\n\n7.cdn和存储主备自动切换\n\n8.跨境质量\n\n\n##### 开发标准:\n\n1.程序日志级别可靠,通过error数量报警\n\n2.程序状态码标准,通过5xx状态码报警\n\n3.核心服务降级\n\n\n##### 架构标准:\n\n1.统一健康检查接口\n\n2.统一下线接口\n\n3.全局服务统一注册,不区分语言和服务类型\n\n4.注册有权重\n\n5.调用方可根据5xx错误次数进行权重熔断\n\n6.发布过程平滑,启动预热(可基于权重小流量)\n\n7.服务调用打点,调用服务名,被调用服务名,uri,状态\n\n8.日志规范可收集\n\n9.链路跟踪,前后端串联\n\n10.限流,应对雪崩场景\n\n11.响应时间\n\n12.mysql限制全局兜底limit\n\n13.ABtest能力\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fliquanzhou%2Fops_doc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fliquanzhou%2Fops_doc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fliquanzhou%2Fops_doc/lists"}