ansible 文档

工作中遇到这么一个场景, 需要给一批Linux服务器部署一个采集服务器基本信息的Agent, 开始打算采用supervisor, 后来由于业务方也在使用supervisor, 为了不影响线上的服务, 打算直接使用nohup的方式启动agent, 但是使用ansible批量部署后没一会儿就退出了, 不管怎么写都是会退出, 后来从网上搜了一下, 找到了答案, 这里做一下记录, 以便以后快速记忆.

ansible -i test.txt all  -m shell -a "nohup /root/node_exporter >/dev/null 2>&1 &"

这里有2点要注意, nohup和&需要有;影响退出最重要的是标准输出的重定向, 如果没有把标准输出重定向的话就会自动退出, 重定向以后就不会自动退出了.

https://github.com/hellorocky/blog/blob/master/ansible/3.%E4%BD%BF%E7%94%A8ansible%E5%90%AF%E5%8A%A8%E8%BF%9C%E7%A8%8B%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%9A%84%E5%90%8E%E5%8F%B0%E8%BF%9B%E7%A8%8B.md

https://jdhao.github.io/2020/01/12/vim_nvim_history_development/

了解自己的技术水平，把握节奏

在开始解决任务时，评估好难点，在解决过程中不断与预估时间对比，超出了预期，需要及时调整，
牢牢掌握住任务的节奏，确保一切都在可控之中。

分清问题主次
对问题分类，区分出来哪些是必须要解决的，哪些是可以忽略的。

你可能会遇到很多问题，这些问题深究下去又会引发很多的问题，如此深度遍历，会导致任务延期，有深深的挫败感。
只解决必须解决的问题，不是必须的但是你有兴趣的问题，记录下来，后续深究。

分而治之
你解决的任务可能别人都没做过，网络上也找不到答案。需要将任务拆散，将有很多背景的复杂问题抽象出来，简单化，去咨询有过相关经验的人，可以使得沟通更有效率，解决问题的速度更快

产品思维
 产品思维的起源是用户价值, 用户价值是通过技术手段以产品或服务的形态去解决用户的痛点, 或带去爽点. 毫无疑问, 工程师在平常工作中应时刻关注并理清自己的工作与用户价值的联系, 并且可以通过聚焦于用户价值去安排工作的优先级和分配自己的精力.

当用户价值足够时, 产品能否在市场中立足并真正收获收益, 首先考验的用户体验. 良好的用户体验一定是站在用户角度, 基于用户的心智来塑造概念, 由于概念存在理解和解释成本, 所以塑造的概念应足够轻, 少且易掌握. 概念一旦塑造出来则概念间的关系也随之确定, 这些关系基本上对定了产品和用户的交互流程. 好的产品体现在易用二字, 其极致在于迎合用户的本能反应并符合各种生活或专业常识.

所有产品都存在演进的过程, 所创造的用户价值也在被不断地挖掘与探索, 那时不同的细化价值需要通过产品特性去区分和表达. 特性也是产品差异化的一种体现, 特性也间接地确定了软件实现层面的功能模块边界. 作为开发工程师, 也需要对产品特性有非常透彻的了解, 并能将其很好地抽象并转化为软件实现层面的功能模块.

为了产品更好地演进, 需要通过数据闭环的形式去校验创造用户价值的效果, 让产品的开发, 运营, 营销的工作做到有的放矢. 在产品价值创造的道路上, 最害怕的事莫过于只顾低头干做加法, 做得多却无人关心收效. 而我们通过数据化闭环的形式, 不仅能让整个产品大团队聚焦于核心价值, 还能帮助团队在探索用户价值的道路上理性地做减法. 大多数情形下, 做减法远难于做加法.

技术思维
 技术思维的源头是需求. 需求可以分为市场需求, 系统需求, 特性需求等不同层次, 回答的是技术层面做什么的问题. 很显然, 清晰表达的需求以及对需求的精确理解才能保证将事儿做对. 毋庸置疑, 需求一旦出现偏差所导致的浪费是非常严重的, 也正因如此工程师对需求的质量相当重视.

需求一旦确立, 会基于模块化的思想拆分成多个功能模块去降低实现的局部复杂度, 最终将所有功能模块拼接在一起去实现整体需求. 每个功能模块会安排给一个人或一个团队去负责, 由于功能是需求分解后的产物, 容易导致工程师在实现的过程中只看到树木而忘记森林.

性能是工程师在实现一个功能模块时不得不关注, 特别是当功能模块被运用于高频, 时效性敏感, 算力有限的场合时性能将尤其被关注. 在现实中有时会存在工程师乐于追求性能的极致去体现自己的技术实力, 甚至出现过早追求性能而滑入过度设计的误区.

毫无疑问, 一个正规的团队, 对于功能模块的开发工作多会以项目制, 多个迭代的方式去完成交付. 不少工程师这里有一个误区, 忘记了敏捷思想所倡导的项目计划的目的是适应变化, 而是将按时交付当做是天职, 各种赶工爬到终点时却毫不意外地看到了一地鸡毛的景象.

在迈向第四次工业革命的道路上, 人工智能, 大数据, 机器学习, Kubernetes, Istio, Knative, Go, Dart, Flutter等新技术不断冲击着工程师已掌握的技能. 快速跟上技术的迭代步伐是每个有追求的工程师不断提升自己专业素养的表现之一. 工程师的内心一定不要缺乏对新技术的追求, 憧憬自己所掌握的技术具有一定的先进性.

工程思维
 工程思维的起点是流程. 流程的背后是科学, 以既定的步骤, 阶段性地输入/输出去完成价值创造, 通过过程控制确保最终结果让人满意. 由于流程涉及每一个工程师的工作质量与效率, 其含义不止在于定义, 工具化, 检查等内容, 而是应基于工程师的日常习惯, 将流程与工程师的工作环境无缝整合. 无缝体现在流程中的概念与工程师群体已建立的专业常识一致, 没有增加毫无价值的复旦, 根本仍是确保易用性.

机制的含义是对所需解决问题的分析, 以一种模式去解决同类问题. 机制应体现一定的系统性, 而非头痛治头, 脚疼治脚. 系统性不是一开始就被洞察到, 可能在演进的过程中逐步发现和完善的, 因而需要工程师在工作的过程中不时回顾并付诸实践去落实. 对于工程师来说, 机制是通过系统性的软件设计去达成的.

可以说产品质量直接决定了工程师的工作和生活的幸福感. 一个质量不可靠的产品一定会给用户和工程师自己带去麻烦, 甚至造成无法挽回的经济损失并造成负面的社会影响. 对于工程师来说, 那势必打乱个体的工作和生活节奏. 为了让产品的质量做到可靠, 单元测试, 静态分析, 动态分析等确保工程质量的手段应成为工程师的基本工作内容, 通过将这些手段与CICD结合起来, 来保证产品质量.

在互联网行业, 除了软件的产品质量可靠以外还有一点要考虑成本.

延伸
 了解工程师的思维的价值在于, 工程是个体需要在工作中逐步建立起产品, 技术和工程三大思维, 以便用更为全面的视角去看待日常工作中所面临的困境和困惑. 当站在单一思维的角度去看待问题的时候可能觉得不合理, 单从三大思维层面去审视所得到的结论可能完全相反. 从团队协作的角度, 只有团队中有更多的个体从多维度去进行思考, 才容易发现岗位间衔接的那些无人问津的灰色地带, 进而通过补位, 助攻去更大程度地发挥团队的效能.

显然不同岗位, 不同职责的工程师对于这三大思维的深度要求是不一样的, 单从多维度去思考是每个工程师都应该具备的素养.