如果IT部门始终被视为成本部门，做事情都要绞尽脑子找公式测算投入产出比，这种情况是非常被动的，IT部门想要做的事情做好了不一定有功，不做则无过，久而久之必然会打击团队做事情的激情性。建议调整汇报策略：1、基于价值交付：不(只)是看成本投入，而是看创建的价值；2、事情的必要性：不...
题主好：这个问题我们也遇到了，说实话，目前还没有特别完备的解决方案。我们公司最最早有基础环境监控（网络、主机、机房等）、之后再建设了应用监控平台（类似ELK的技术栈）、最后才建设了自动化运维（变更）平台。这些平台一开始互相之间都独立且不相关。现在我们正在做一些尝试，进行合...
脚本区分为 查询功能 和 修改功能脚本版本需要进行管理脚本权限需要管理脚本审核流程脚本危险操作命令提示执行历史完整保留
运维开发实际上没有想象中那么难，最好是有2个到3个人一起搞，效果会好的多，知识也可以互补。主要是学习开发语言的使用，然后先做一点小东西，最好慢慢的可以整合起来，这样的话整体就出来了。前段时间做了一个使用python自动发短信，后来想想短信多费钱啊，那就使用微信吧，很短时间也就...
最困难的是 配置不统一,各个系统配置完全不一样,导致 运维复杂一个没有统一规范的 基础架构环境 就是运维的噩梦了
需要从业务需求，从网络和系统环境现状，从系统架构未来的发展，从人员的技术能力和诉求，包括如果你是银行，还需要考虑监管和流程，都要进行考虑，如果仅仅是针对技术和工具，我的建议如下自动化运维底层工具一般会包括如下：CMDB及配置自动化发现工具；2.脚本及作业管理中心；3.Agent及管控...
ssh有先天缺陷：安全性低、效率低。但是其使用和部署方式相对简单。适合小规模应用。开源agent如saltstack等安全性、效率都相对较高。缺点之一是系统功能需要在其接口上进行开发。开发agent成本高，好处是可以自主掌控，灵活定制。我们公司经历了 SSH-开源agent-自研agent的发...
1、平台考虑进行一些微服务化的设计，功能分离成相对独立的服务，部署在容器内，实现动态扩容就很容易了。2、对纳管服务器的代理执行效率，一般情况下需要达到并发几千以上。这种并发效率对于一般企业使用足够了...
