关于 devops 在日常工作中真实形态的困惑

基本做 dev，ops 有相关人做。调调 api 啦~

其实，ops 没那么简单，所以要一个人照顾到两方面，确实需要很强能力

我是 xabcloud.com 的工程师&负责人,我想我应该可以回答这个问题, 关于 DevOps 我这边理解的非常简单，就是让 Dev 自己去 Ops 自己的开发的应用或者系统，曾经在阿里的时候，阿里的开发同学都是可以随时申请线上机器的登录权限的，这样可以非常快速高效的查看线上问题，后来有幸去有赞，了解到有赞的开发工程师都是有线上机器 root 权限的，而且可以说管理的非常宽松，有赞团队高效率也是非常值得一提的，这里我就简单总结，开发团队的技术素养 和 对线上权限适当的放开，这就是 DevOps 提高团队效率的关键所在

可以看看自己公司和有效率的公司，对线上权限这块的管理规范，是否过于约束，是否迫于运维同学的约束，流程不太方便？

一堆技术人员，一堆机器，如果企业运维同学不给力，必然造成机器管理的混乱；我有个同学是某著名 X 信的工程师，后来离职，我们吃饭聊天的时候，聊起来说他现在还能登录原来公司的机器 😄，还是相当大的企业

1 把机器名称规范化，以应用分组规律，机器管理不混乱
2 自助式机器权限申请，审批，流程简化
3 统一内网入口机器，而不必去记忆各种 IP
4 应用分组维度实时监控

把这几点做好，基本就足够了，解决了运维的困扰，然后下大力气在自己核心业务，这就是我这边从客户那里感受的效率

DevOps 在我理解，更偏向于一种软件架构，它与微服务紧密不可分割，把原先运维的事情抽象打包为各个微服务，这些微服务从生至死由该团队负责，这些微服务使用对象主要为业务开发人员，只有当这些微服务工具足够完善，业务开发人员才可以更专注于各自的业务逻辑。

@ywgx 请教下，有赞的开发工程师有线上机器 root 权限，如何解决数据保密问题（这么多电商用户数据），还是纯粹信任工程师，没做任何技术上的防范措施？

@shiny 我在的时间比较短，这里只能简单说下当时的情况，统一内网入口地址，登录线上要连 VPN, 更重要的是截获了 内网入口机器的 IO 流，这样无论是登录到哪台机器都是有记录可查的，当然权限再开放，也是相对的，如果不是你的业务机器，你申请可能不会被审批； 至于关键数据 大部分是对数据库而言吧，当然是有权限管理的； 现在或许更加成熟了，期待有赞的同学看到解惑下

@ywgx 很有借鉴价值，感谢答疑。

现在对于运维，一种叫堡垒机的东西用的很多。大概和楼上所说的 VPN 差不多，统一的登录入口，权限管理，哪个人连的哪个机器做的什么操作都有记录

@iAcn 记得很多年前，很多公司是提供一个堡垒机，能使用的 ssh 命令也是受限的，因此有些人想办法绕过限制。

我的工作主要是对接程序员和项目经理
1. 架构定下来以后写自动化部署代码，所有环节配置版本化。
2. 日志即时反馈，目前刚上 ELK，分角色提供测试、线上环境的实时日志查看
3. 监控所有服务器状态，并根据实际情况不断优化自动扩展（ Auto Scaling ）配置

@ywgx #2 冒昧问下，不知道还有没有跟 xabcloud.com 类似的服务？……想对比一下

@Loyalsoldier 说真心的，目前还没有发现；我这边是参考海外 saltstack.com 企业版本实现的，其中权限管理和监控模块是我们自己开发的

a.devops 更多是风格 /公司结构，而非具体岗位 b. op 尤其是手动的 op 占比较大的那就不是 devops 了，需要值班的自己写代码监控，需要反复操作的写脚本，需要查日志的搭日志收集 /检索…

至于生产 root，我还没见过哪家互联网公司是开发拿不到生产 root 的，最多需要业务条线老板审批下，堡垒机记录操作，或者两样都要。好点的就是 root 和 www 分开，www,日常用，root 另外申请

@shiny 很早前是用跳板机的，软件记录操作，现在直接上硬件堡垒机了😂