帮现在的东家发布个招聘信息，主要是运维相关职位，职位信息如下描述。
发展潜力巨大，技术氛围很好，欢迎各路英雄前来！简历发送至： sky000 at gmail
- 系统管理工程师
- 岗位描述
- 负责公司网站的主机硬件维护，部署以及系统级软件的维护部署升级工作
- 负责公司网站的存储设备的维护及部署工作
- 负责公司内部开发测试主机的硬件维护，部署及系统级软件的维护部署升级工作
- 负责制定系统运维规范，并推进实施
- 配合应用运维工程师处理线上应用的运维需求
- 24*7 standby
- 技能需求
- 良好的沟通技能和团队合作能力
- 精通 Linux/Unix 系统的维护管理
- 熟悉 Linux 下 Mail/Web/DNS/LVS/CDN 等服务器的搭建及维护
- 熟练使用 Shell/Perl/Python 中的一种
- 2年以上系统管理工作经验，1年全职系统管理经验
- 熟悉Apache，Tomcat等Web服务器的部署及维护
- 网络工程师
- 岗位描述
- 负责公司网站所在 IDC 的网络硬件设备的部署及维护工作
- 负责公司网站所在 IDC 的网络架构的设计和优化
- 负责公司网站所在 IDC 的网络环境的日维护
- 支持系统管理和应用运维工程师进行日常网络变更需求的处理
- 负责和各运营商的协调工作
- 24*7 standby
- 技能需求
- 良好的沟通技能和团队合作能力
- 精通 交换/路由 原理
- 熟悉 TCP/IP 协议
- 熟悉主流厂商（思科/华为）网络设备的管理维护
- 熟悉 VPN 和网络防火墙的部署，配置及维护
- 熟悉 Shell/Perl/Python 语言中的一种
- 配置管理工程师
- 岗位描述
- 负责公司网站技术部门的配置管理规范制定及实施推进
- 维护编译发布环境，对系统进行版本管理
- 维护管理配置数据库，优化/规范发布流程
- 管理维护公司 SVN 代码库
- 优化规范公司发布流程
- 协助开发工程师进行 SVN 分支维护
- 协助应用运维工程师进行发布部署工作
- 技能需求
- 良好的沟通技能和团队合作能力
- 对 SVN 有较深入理解
- 熟悉 SVN 的部署，管理及日常维护工作
- 熟悉 Shell/Perl/Python 中的一种
- 有1年以上全职配置管理工作经验
- 应用运维工程师
- 岗位描述
- 负责公司网站的应用部署，升级和维护
- 负责研发团队的系统响应和处理，日常应用运维工作
- 负责研发团队的产品发布上线，发布脚本和环境维护
- 负责应用集群的合理规划
- 负责制定应用运维规范，并推进实施
- 24*7 standby
- 技能需求
- 良好的沟通技能和团队合作能力
- 熟悉 Linux 系统日常维护及优化
- 熟悉 Apache，Tomcat 等 Web 服务器的部署，维护及优化
- 熟悉 Shell/Perl/Python 语言中的一种
- 有应用运维或者系统管理经验者优先
- 数据库工程师
- 岗位描述
- 负责管理维护公司线上数据库，确保数据库99.99%稳定运行
- 负责管理维护公司开发测试数据库，确保数据库95%稳定运行
- 支持开发工程师解决数据库开发相关问题
- 优化 SQL 语句，优化数据库Schema结构，优化数据库
- MySQL 数据库高级特性测试，优化及实践
- 负责制定数据库开发/维护规范，并推进实施
- 24*7 standby
- 技能需求
- 良好的沟通技能和团队合作能力
- 精通 SQL
- 熟悉 SQL Tuning
- 熟悉 MySQL数据库系统架构及其管理
- 熟悉 MySQL Replication实现原理
- 熟悉 Linux 操作系统
- 熟悉 Shell/Perl/Python 之中的一门
- 监控工程师
- 岗位描述
- 负责维护公司监控系统的开发及维护
- 负责公司网站相关的软硬件设备的日常性能及报警监控
- 根据监控系统收集的各类数据的统计分析，进行容量规划
- 根据监控数据推进相关部门进行网站响应速度方面的优化，提高用户体验
- 24*7 standby
- 技能需求
- 良好的沟通技能和团队合作能力
- 精通 Cacti/Nagios 配置管理
- 熟练使用 Shell/Perl/Python 中的一门
- 有 Java 或者 PhP 开发经验者优先
上周北京出差，参加了 CSDN 主办的 TUP 技术沙龙 和 CTO 俱乐部 的活动，有幸受邀分享了一下 B2C电子商务系统的数据层构建相关的内容。
在参加 TUP技术沙龙和 CTO 俱乐部活动的时候，同时还听了凡客项目管理与架构总监栾义来的凡客历程分享，以及百度基础架构部高级工程师马如悦的hadoop相关的分享。
栾义来的凡客历程分享中比较突出的几个观点：
- 业务绝对优先，不要过度强调技术架构
- 不理解生意，无法做系统
- 解决了数据库问题，就解决了80%的问题
马如悦关于Hadoop的分享比较技术，了解到的最让我印象深刻的信息就是百度的Hadoop集群大小已经超过了Yahoo的集群，成为目前全球最大的Hadoop集群。
下面是我的PPT，主要介绍了3个方面的内容：
- 常见高可用可扩展方案（这部分内容以前在 OOW 的 OTN Lounge分享过）
- 利用日志解析针对 B2C 电商系统特点扩展系统
- 利用MySQL Infobright搭建电商系统的分析推荐引擎
architect, B2C, MySQL
随着数据存储技术的迅猛发展，随着各种 NoSQL 技术的产生，无论是我们同事之间还是整个互联网行业，都出现关于“分布式 数据 存储/处理 解决方案”方面的选择分歧。就我目前所了解到的主流意见主要有以下三种：
- 去关系型，NoSQL是王道
- NoSQL靠边站，关系型才是王道
- 以关系型为核心，NoSQL为补充
三种意见中前面两种观点较为极端，都是“非对即错”的选择，当然也有更为理性的第三种方案。
如果作为开发人员，从我目前所了解的信息来看，主要还是倾向于第一种思路。因为在他们看来，分布式的 NoSQL 系统是一个非常美的架构，不仅仅解决了扩展性的问题，同时也解决了可靠性问题，同时还可以让程序开发免去关系型模型的约束，不选择他才是傻子呢！
从我个人的角度来看，我目前更倾向于第三种思路，至少在现阶段是如此。
Why？
但是如果是从运维的角度出发，所考虑的风险点可能完全不一样。作为一个存储数据的核心组件，在需要对其数据进行人工订正维护的时候是否方便操作？在需要抽取其中某部分数据到线下给开发/测试部门使用的时候是否方便？最重要的是，当他整个 Crash 之后我们可以怎么恢复？当我们面对这些问题的时候，我们是否有合适便利的手段来避免或者解决？
确实，理念很完美，架构很完美，但目前的NoSQL产品的实现是不是真的也如此完美呢？我想没有哪个产品敢拍着自己的胸脯说他们的产品不会Crash，就像没有厂商向我们保证他们的硬件在达到标称的使用寿命之前不会损坏一样。既然存在整个 Crash 的可能，那就必须考虑如何应对。我们不能只是考虑这个听上去完美的分布式系统在某个节点 Crash 之后可以很好的”自愈”，不能只考虑当目前整个集群资源达到瓶颈之后仅仅只需要在线增加一个节点就可以”自我完成负载/数据重分布”。我们还需要考虑他的整体可靠性，还需要考虑更为恶劣的环境更为残酷的场景下，他是否还能生存。
关系型数据库在刚开始产生的时候，同样面临了各种各样的问题，同样受到过大量的质疑。但是，当他在风风雨雨中走过了这么多年之后，通过不断的完善和适应，不论在灾难恢复方面还是在可操作性和可维护性方面都做了大量的工作。当然，在这么多年的市场需求下，也培养出了大量的专业技术人员。但 NoSQL 发展到现在，才经历了很短的时间，缺少在恶劣环境下的磨炼，缺少复杂环境下的检验，更缺少有丰富经验的专业技术人员。在这种情况下，你还敢轻易决定将一个公司最为核心的资本（数据）轻易从关系型数据库中迁移出来吗？
当然，我们并不一定要一个完美的产品，就像我们无法让我们自己成为一个完美的人一样。但我们必须清楚一个产品的可能存在的风险和缺陷，并且清楚如何做能避免这些风险和缺陷，同时还要让我们自己有能力避免这些风险和缺陷。只有在这样的前提下，我们才会在比较重要的场景下使用。但要积累这些经验，积累这些信任，培养专业技术人员，都需要一定的时间。
所以在我个人看来，在近几年，NoSQL 暂时还不可能成为数据管理软件领域的主角，仍然只能作为特定场景下的数据存/取解决方案的补充，即使在互联网行业也是如此。至于在未来，比如五年十年以后会是什么样子，我就无法预测了。
注：文中观点仅代表个人，基于个人目前的认知，欢迎大家拍砖！
时常遇到一些希望从多个 MySQL 实例将数据复制到单个MySQL 实例上的需求场景，又苦于原生的 MySQL 并不支持这样的实现方案，开源社区中也没有哪位大拿提供解决这方面需求的插件。 有时候就想，要不公司里面组织力量修改一下 MySQL 代码来搞定这个问题得了。可转念一想，后面如果需要升级版本的时候怎么办呢？再修改一次代码？这样的成本有多大呢？如此的问题让人很是纠结。 最近突然想明白了：为啥非要在现在代码中来实现这个需求呢？为啥不能通过在外部想办法呢？我们需要的不是看上去的美，而是最终的结果。看上去漂亮完美的架构方案并不一定就是最好的。 如是就有了下面这样的想法：
- 通过在 Master 和 Slave 之间增加一层复制代理服务
- 多个线程连接上多个 Master 上请求 Binlog（完全模拟 Slave 上的IO线程）
- 多个线程连接上单个 Slave 实例，直接以类似于应用程序的方式并行应用 Binlog中的Event（部分模拟Slave 上的SQL线程）
- 由于很清楚业务场景，在应用线程方面可以在一些特定规则约束下实现并行应用以改善 Slave 端延时
由于 MySQL 开源的特性，实现上述功能其实很简单，还可以保持原生 MySQL 不会被动任何手术即可完成我们的需求，看来是该动手的时候了。
BTW： 我的需求中，各个 Master 中的数据是不会有任何重叠的。
前几天，受 Oracle 所遥，在 OOW 上的 OTN Lounge 分享了一下最近一年来在利用MySQL 在高可用可扩展架构方面的一些心得，这里贴上 PPT，供大家拍砖。
内容方面，前面的部分可能有不少朋友以前有看到过，可能是听我介绍过，也有可能本身自己就对这些架构很了解。无所谓，只要能对一少部分人有用，那也欣慰。不过，最后两页 PPT 的内容，我想肯定没有人在其他渠道见过，因为这两张图片是我第一次在公开场合展示。
废话少说，上 PPT 吧，呵呵！
