– 过程要有邮件总结与输出,定期向boss汇报
– KPI是手段,但更是入场券、分数线
相对于业务里的亮点,KPI是必要条件。
– boss的想法就像狐狸,是跟着狐狸尾巴跑,还是跟着脑袋,这是个问题
– 一味模仿、一味追随很忙很累,也容易被人远远甩在后面
– 管理boss预期
要相信你在业务上是专家,当然,最好要有依据支撑
– 我平常有些事情答应太快,同时也缺乏持续的目标
巴厘岛会议感想
15
– 过程要有邮件总结与输出,定期向boss汇报
– KPI是手段,但更是入场券、分数线
相对于业务里的亮点,KPI是必要条件。
– boss的想法就像狐狸,是跟着狐狸尾巴跑,还是跟着脑袋,这是个问题
– 一味模仿、一味追随很忙很累,也容易被人远远甩在后面
– 管理boss预期
要相信你在业务上是专家,当然,最好要有依据支撑
– 我平常有些事情答应太快,同时也缺乏持续的目标
周末参加了2009系统架构师大会,期间对自己感兴趣的话题做了部分笔记,现摘录如下:
童剑 新浪高级系统架构师,研发中心平台部总监
- 资源监控 - HA Xen虚拟化 - 数据库集群 2006年点击量3亿/天 实时访问统计,考虑恶意访问 代码分发、数据库集群、软件仓库 高可用、低成本、可扩展 - 无单点故障 - 基于开源软件 - 各部门共享、对外透明 统一运行环境 - 统一配置 简单映像体系 (程序员看来)一个数据库、一个前台、一个缓存 架构图 |---> Cache ----->| 负载平衡 --| \|/ | VFS |---> App ------->| 用到的软件 - LAMP - Memecached - Squid-Cache - Heartbeat + DRBD - Xen - Cfengine - Bind DNS + Mon - Haproxy 一些经验 - 借鉴成功经验 如LiveJournal(Memcached、MogileFS)、Yahoo、Google、FaceBook等 - 使用成熟软件 重复造的轮子维护困难、不便于交接 - 底层封装和隔离 可扩展 - 简单 = 高效 够用、分阶段完善、简单(结构设计+实现方法) = 高效(开发过程 + 故障排除) 标准化配置 - 好处 开发生产分离、配置文件 - 运行环境配置 软件包、版本、路径、用户等 记录请求时长、MySQL慢日志 常用配置统一 - 其他... 约定和限制 - 基本约定 读写分离、缓存尽量使用Memcache、不用绝对路径、程序目录+x-w、数据库目录+w-x、不使用长连接、耗时查询小于1次/分钟 - 必要配置 涉及PHP安全方面的配置等 监控报警 - 详细感知 - 自动控制和修复 - 日志统计分析 - 数据监控 * 可用性(ping/port/disk usage) * 容量(带宽、磁盘、CPU) * 质量(响应速度、成功率) * 异常(进程、访问量) - 主动处理尝试 * 拒绝恶意IP * 暂停异常服务 * kill异常进程 - 报警 * 仪表板 * Email * SMS * IM 性能 - 高可用 - 开发语言的选择 如果对CPU等资源占用不大,可选择解释性脚本语言(C虽然高效,但是从头再来毕竟耗费人力物力) - 选择合适的服务器软件 高并发高IO时可选择Nginx/lighttpd - 软硬件因素 - 网络性能 应熟悉常见现象 - 性能分析 对症下药才能治本 容量规划 - 负载 < CPU的核数 - 平常占用资源的40%,峰值80% - 60%扩容 - 20% 保留给系统管理和监控使用 提问:如果多个机房中的某个机房的服务器出现问题,怎么做到切换服务器不影响访问? 回到:在DNS里设置某个域名的相应时间,所有Name Server都应该遵循该规范
吴静涛:F5中国技术总监,高级架构师
- 柔性可用 - 客户诊断 - 降级服务 故障梯度服务(以qzone为例) - 100% 最优 - 80% 取消增值服务 - 50% 基础功能 - 20% 核心功能 - 5% 公告 缓存、性能 - 用户端Cache - CDN - 核心动态数据 - 提升动态数据能力 TTC : 腾讯内存Cache集群 TTC1、TTC2 ----> DB TTC1、TTC2 --> TTC0 ---> DB - UGC内容放入存储平台 - 按需加载 - 检测平台、持续优化 其他 - 产品削锋填谷 以前一天只允许在0点开始买卖奴隶,造成该时段访问压力特别大,经产品策划协商, 更改策略:一天内0 - 9点均可开始买卖努力,但早上6点前买卖奴隶收入减半。。从 而通过策略将峰值下降很多 - 集群、轻量、标准 GSLB + LVS + Qzhttp - 轻量内存 TTC + MySQL - 逻辑? S++ ? - 海量数据存储 TFS、TDB - 削锋填谷 * 明星 - 低 * 金牛 - 合理 * 瘦狗 - 高 其他:采集用户打开时间、多写少读(可在内存里积累一定的程度再去写)
程立:支付宝(中国)网络技术有限公司 首席架构师
- SOA 性能、响应时间、指标 Async异步调用、future异步调用 - 容量 * 估算新业务上线对容量的需求 * 服务吞吐量优化 - 服务吞吐量 - 伸缩公式 - 伸缩上限 - 单个资源吞吐量上限(串行处理) * 解决 - 充分扩容 - 平衡扩容 - 消除单点瓶颈 * 资源使用分析、SQL执行次数 * 单点故障 - 并发请求 - 重复请求 - 超量请求 - 请求挤压 - 其他 * 局部配额、令牌 * 幂等控制、操作日志 * 并发控制 - 经典方法(事务) - 乐观方法(减少事务使用时间) - 分布锁(生命周期、防止死锁) * 请求丢弃 过期就丢弃相应的请求 * 时间控制 整体服务期限 * 分布事务 - TCC模式 Try - Confirm -Cancle - 补偿模式 Do - 补偿
李晓栋:新浪网研发中心架构部 技术经理
- QOS - TCP/IP协议先天不足 - 管理心得 * 集中管理 * 监控报警 * 负载分析 * 服务配置 - 原则 * 高性能 * 高可靠性 * 高可管理性 - 流量快速分析 * MRTG、ARTU * netflow、sflow、SNMP、Sniffer(pfring) * payload、wireshark - 平台使用方法 * tcpdump抓包 * 上传pcap包 * 选择分析条件 * 输出分析结果 - misc * 交换机(prot-channel) * LVS特殊单臂解决方案 * PK麻烦且变更不便 * 利用iptables获取TCP端口流量统计 * 网页挂马的JS?
岑文初: 淘宝网开放平台架构师
- 异步交互、通知 * 保持会话、支持异步(短信) * 异步延时(大数据管理信息) * 订阅关系维护、支持通知服务(系统间数据同步) - 服务分流与隔离 二级域名(某API) --> 软负载(LVS、7层包、HA) --> 软负载 + 虚拟服务组(图) 上下文缓存 - 本地缓存、远程缓存 - 商业方面 * 流量收费(调用接口) * 插件分成
陈吉平:淘宝网技术总监、首席DBA、DBA Manager、Oracle ACE
- 分布式 分布式存储(TFS)、分布式Cache(Caire) - 高可用之双机房架构 Data Guard + Redo mirror - V3.0垂直扩展 用户、商品... 非核心数据使用MySQL - V4.0 水平扩展 - 读写分离 - V4.0 水平扩展 - 水平拆分 * Scale Out * 压力动态平衡 * 支持任何数据库 - Amazon、S3、EC2、Simple DB - C1 读写分离 * 主库集中,读库水平分割 * 写操作、部分重要读操作回主库 * 读库故障可回主库 * APP -> TDDL * 数据路由、数据复制 - C2 水平分割 * 16DB 1024张表,单表16亿条记录 * 避免无限制分表 * 没有主数据库 - 监控 * DB、Host * SNMP ? => Agent??
叶金荣:搜狐游戏高级MySQL DBA
- 常用命令 * vmstats vmstatus -s n 3 * iostats * pidstat * mpstats * top * sar - 诊断方法 * mysql slow query * show engine innodbstatus * profiling * mysql report - 杂项 * 禁用swap * micro slow补丁 可显示详细执行计划 * mysqlsla * 数据库擅长的事情:存储数据 + 事务 * query cache可适当降低,可通过profiling查看,太大会引发新问题 * sending data值的设置 只查询需要的字段即可 * freeing items * 关闭binlogs * ssd 文件系统优化 * xfs文件系统存储单个大文件有优势 * 静态编译mysql速度也会提升 * DNS管理系统 * innodb buffer * 5.0.77 higerreat版本 - 一些引擎 * MySIAM * InnoDB * TukoDB * XtraDB * Memcache for MySQL * waffle Grid Project - InnoDB Plugin 1.1 * 可快速创建索引 * 数据压缩 * 可在线设置是否单表使用空间 - misc * OLTP/OLAP 应用类型 * COUNT(*)将进行全表扫描、InnoDB的表推荐使用COUNT(PK)
update:
随着时间的积累,以前大家的工作方式逐渐变得混乱,领导审时度势组织大家开了一次小会。本没有对这场中午的小会抱多大希望,但“develop with pleasure”的主题货真价实,听完之后犹如醍醐灌顶般恍然大悟,感觉以前没有头绪的事情一下子有了眉目。
对于维护上线的web项目,以往的做法是发现错误随时更正。这种松散的方式看起来很辛苦,但效率总是不高,而且还极易处于被动的地位。另外一种方式的好处就显而易见了,根据各种需求、计划、决策、反馈制定一个短期的版本计划,定期发布。根据该计划,线上的每次改动都将对应代码仓库里的一个版本,这样即便是某次发布时出现错误,也可以很容易恢复到稳定版本。除了版本发布操作,不再零散更新线上的文件。如果想灵活一些,还可以缩短计划中的开发周期。
以前没有仔细考虑过类似的问题,或许这只是项目管理中的冰山一角。其实很多事情都是相通的,就拿上文中的按计划发布版本来说,早在大学时班主任就曾多次向我们灌输计划、总结的重要性,当时可能也听了,只是没真正体会到它的重要性。
总之一句话:事前计划,事后总结。
就这。
btw,新增一个”快乐开发 | developer”分类,今后用于存放类似问题。