3.对云计算而言，一大堆机器和设备放在一起，安全成为了一大挑战。
没有云计算的时候
一大堆机器和设备放在一起
非常安全
最后一句话 。。。
alfah 发表于 2015-03-02 16:24 static/image/common/back.gif
没有云计算的时候
一大堆机器和设备放在一起
非常安全
1.云计算时代，运维人员是否会面临着失业的风险？
还奉行老思路吃老本的大龄运维，其实已经相当危险了，存在感将不断下降，手工作坊式的低技术含量运维将越来越out。建议年轻入行的运维，一定要多学点开发技术，光会用几个开源工具，养不起老婆孩子的。
2.传统的数据中心里，设备是真实存在的，管理起来相对简单，而虚拟化技术将这些资源都“池化了”，一旦故障发生，需要检查排除，云时代下您觉得在运维管理方面存在哪些痛点困扰呢？
如果是公有云，那完全没脾气，只有选一个服务好的厂家了。如果是私有云，自己可以把原理性的东西研究清楚，提高troubleshooting能力。
3.对云计算而言，一大堆机器和设备放在一起，安全成为了一大挑战。有哪些监控工具可以实现对资源的管理，对网络流量、CPU利用率、进程、内存等状态监控呢？
saltStack、puppet、nagios、cacti、zabbix。。。现在有一堆开源监控和配置管理工具了，但问题是，如果只是会用这些工具，运维的价值何在？作为一个有理想的运维，应该搞点自己的小工具，成为这些工具的补充。
4.在使用云服务，比如阿里云、腾讯云等，磁盘用到一定时候就会不稳定，很莫名其妙，磁盘I/O会变慢，到底是什么原因？您是否遇到过类似的经历？当时是如何解决的？
有冗余，不用怕，往往重启后就恢复了。具体原因，还得问厂家。
5.考虑到安全性问题，大多数企业都会选择混合云，选择IBM的云，稳定但贵，您比较看好哪些云服务提供商？为什么？
看企业老板是什么思路，有的不差钱，有的很差钱。贵的一般都好一些。
1.云计算时代，运维人员是否会面临着失业的风险？
难道云计算时代就不需要运维人员？至于失业只有那些不肯学习，固步自封的才会，云时代的运维更复杂，技能要求更高
2.传统的数据中心里，设备是真实存在的，管理起来相对简单，而虚拟化技术将这些资源都“池化了”，一旦故障发生，需要检查排除，云时代下您觉得在运维管理方面存在哪些痛点困扰呢？
主要是自动化程度高导致很多运维搞不清楚里面实现细节，从而导致排除查找问题复杂
3.对云计算而言，一大堆机器和设备放在一起，安全成为了一大挑战。有哪些监控工具可以实现对资源的管理，对网络流量、CPU利用率、进程、内存等状态监控呢？
监控方面个人认为以定制化为主，通过对开源工具如zabbix等定制开发
4.在使用云服务，比如阿里云、腾讯云等，磁盘用到一定时候就会不稳定，很莫名其妙，磁盘I/O会变慢，到底是什么原因？您是否遇到过类似的经历？当时是如何解决的？
没有类似经历
5.考虑到安全性问题，大多数企业都会选择混合云，选择IBM的云，稳定但贵，您比较看好哪些云服务提供商？为什么？
个人比较看好亚马逊和微软云
哈 你这帖子居然是周六发出的 果然周末在上班 ~~
shang2010 发表于 2015-02-28 18:23 static/image/common/back.gif
活动奖励：选取优质回帖会员，赠送技术图书。
1.云计算时代，运维人员是否会面临着失业的风险？
个人感觉不大会：
1.就算是在云服务器上使用，也是会存在机器故障，性能优化等需求。
2.现在用云服务器的一般为刚起步创业公司，个别非科技公司以及有自己云平台的大型公司，大中型公司为了保证自己的数据安全，还是会选择自己有的机房去进行存放。
2.传统的数据中心里，设备是真实存在的，管理起来相对简单，而虚拟化技术将这些资源都“池化了”，一旦故障发生，需要检查排除，云时代下您觉得在运维管理方面存在哪些痛点困扰呢？
其实排错方面的方式还是一样的，只是考虑的方面多了些；况且大多运维都会使用虚拟化进行工作，所以应该都比较熟悉。
3.对云计算而言，一大堆机器和设备放在一起，安全成为了一大挑战。有哪些监控工具可以实现对资源的管理，对网络流量、CPU利用率、进程、内存等状态监控呢？
本人在用的就是：zabbix,Cacti ,扩展性比较强，可以自行编写脚本进行监控。
4.在使用云服务，比如阿里云、腾讯云等，磁盘用到一定时候就会不稳定，很莫名其妙，磁盘I/O会变慢，到底是什么原因？您是否遇到过类似的经历？当时是如何解决的？
具体情况还是没有遇到过。
5.考虑到安全性问题，大多数企业都会选择混合云，选择IBM的云，稳定但贵，您比较看好哪些云服务提供商？为什么？
个人对 清风 感觉还不错，即时计费而且性能可以按需分配机动性比较大。
我们知道人脑的方式是并行化的，很多神经元通过树突和轴突来进行信息交换和传递。这些信息在传递的过程中同时也影响神经元，从而最终形成决策。我们的大脑最上层是皮层，其下是深层结构。如果我们将计算机的单个计算节点想象成一个神经元。那么目前的物理网络则可以理解为一个逻辑上超级大的计算机的深层结构。那么再往上这个超级计算机的皮层物理形式我们可以理解为SDN或者类似SDN的软件化数据传输通道，随着计算单元的不断小型化。我们发现计算节点的物理尺寸也越来越小。那么我们的传统数据中心里将容纳更多这样的计算神经元。深层结构的网络连接起这些神经元节点。这些神经元形成的“皮层”也需要新的理论体系架构来进行定义和表述。我个人认为SDN正需要向这个方向发展和进化。这样我们的超级计算机集群系统将在并行集群的通用性和集群部署的通用性上取得新的进展和发展空间。新的超级计算机体系正在形成和崛起。虽然这些都是才刚刚起步。我们应该赋予每个神经元节点一种能力。从而自下而上的实现“皮层”功能。而不是自上而下的通过所谓的管理来实现这样的功能。
无状态高性能网络协议 Trickles将让神经元的连接更高效。这为“皮层”特性提供了技术上的准备和支持，这是SDN需要努力的方向。
DOCKER作为LINUX系统中一个非常前卫的应用容器，在2014年里受到了广泛的关注，各种讨论让人眼花缭乱。我们似乎能感觉到DOCKER要接管一切应用了一样。然而，到目前为止我个人觉得DOCKER还处在一个发展的实验性阶段。DOCKER听起来很高大上。但似乎又让我们感觉到它并不那么容易就可以让人使用。这种感觉很像当年刚开始使用KVM时一样。当初我们如果需要使用KVM来建立一个虚拟机，那个过程是非常复杂和需要认真对待的。不像现在我们使用KVM创建虚拟机，对于一个系统管理员来说基本不存在什么问题。整个创建过程中系统管理员都是在对当前计算机系统的各种资源进行操作。这样，系统管理员就掌握了更多的对系统的权利。现在的DOCKER似乎让人感觉要复杂很多。最重要的问题就是整个底层的东西让系统管理员们有点迷茫。很多东西的控制权已经不再属于用户本身。比如创建IMAGES。同时很多时候我们必须要进行联网才能进行操作。DOCKER是一个容器。说白了其实就是LINUX里的一个应用程序。本来它应该首先成为LINUX里的一个本地组件。就像KVM那样。在这个组件之上用户可以来展开自己的应用。而现在DOCKER感觉不是这样的。本地源的缺失让用户们头痛不已。也让DOCKER看起来很高大上。而推向真正的用户却无比的缓慢。
回复 21# niao5929
年纪越大，越怕新技术。很多公司，落魄的30+大龄程序员，工资未必有新招聘的25岁干app开发的高。
所以，docker进生产慢一点，没啥不好的。:mrgreen: