一个技术码农的感悟

1. 干 货
小马
Weibo ID: @zodiac0079
Mail: mxzodiac@gmail.com
Blog: http://fundev.in

2. 理想中, 我们总希望自己是这样的

3. 但现实是残酷的! 我们往往是这样的

4. 我们今天就来聊聊如何拉近理想和现实之间的距离

5.  明确目标
 建立标准
 管理代码
 打造工具
 运维生产
 利用数据

6. 明确目标
有时候开发、测试及产品人员间对同一产品的预期是不同的, 导致了开发理念上的差异

7. 我们经常会听到这样的声音

8. 面对这些需求, 有时候我们会产生一些疑问
1. 产品的最终用户是谁?
2. 产品功能是否在为最终用户服务?
3. 用户真正需要什么?
4. 需求是否太粗略了?
5. 需求有实现的价值吗?
6. 要实现哪些功能?
7. 功能的细节怎么定义?
8. 有更好的实现吗?

9. 解决问题 - SMART法则
1. S － Specific
这里指的是目标一定要明确的（ specific ) 不能够模糊， 时间上的 6 - 2 – 2 分配
2. M － Measurable
目标的可度量性。 制定的目标一定是可以度量的
3. A － Attainable
目标的可实现性。一个目标必须是可以实现的，或者说经过努力是可以实现的
4. R － Relevant
目标必须和其他目标具有相关性。 即一切努力都是为了一个结果，而不是为了行动
5. T － Time-based
目标必须具有明确的截止期限。 即一个目标只有在一定的时间内达成才有意义

10. 解决问题
1. 及时讨论 站立式会议等
2. 确立文档 明确需求、实现细节等
3. 制作原型 Axure 等
4. 外部反馈 测试、监测、客户反馈等
产品 开发 测试
开发 测试
产品

11. 提问
回答

12. 建立标准
我们都是渴望自由的代码猴子, 但重复造轮子绝不是我们的作风

13. 在多个项目切换中是不是常会碰到这些问题

14. 问题
1. 多种不同的 UI / UE ，不易管理和维护， 增加设计、开发、测试成本
2. 代码相似功能的重复实现，相同功能重复测试
3. 多项目间，相同服务需要重复建立，服务器资源会被浪费
4. 多项目部署有差异，难以维护
5. 各项目发布机制差异，难以建立统一、方便、安全的发布体系

15. 解决问题
1. 对 UI / UE 设计一份标准和规范, 通用于多项目中
2. 前端使用统一的解决方案, 使用UI标准控件（使用Dojo，上层自行封装UI组件）
3. 建立后端跨项目标准服务（MySQL、消息队列、LVS、静态资源服务 、GEOIP 等）
4. 定制环境项目结构标准, 降低运维成本，可用于未来开发统一的代码发布回滚机制
优点
1. 标准化能够降低开发、设计、测试成本, 提高项目产出效率
2. 统一的 UI / UE 对产品线的建立也有帮助
3. 服务标准化有助于虚拟化环境建立，方便项目的水平扩展，更有效利用服务器资源
4. 项目结构标准化, 有利于设计统一的项目生产发布/回滚机制

16. 折腾这些值得吗？我想是的

17. 提问
回答

18. 管理代码
总有些代码让我们抓着头皮，嚷着WTF或者是FTW～或者准备拿起菜刀～

19. 或许我们还在发愁

20. 或许其中就有一坨是我写的～
但我们今天讨论的是如何避免再次出现呢？
Fire小马？
我们有更好的办法～
No！

21. 解决问题
1. 建立代码规范（PEP8、Google Style Guide、JSLint 等）
2. 使用代码规范检测工具（JSLint、JSHint、Pep8Lint 等）
3. 代码审计（Redmine、Gitlab 等）
4. 代码文档注释 （Markdown、JSDoc、 Sphinx 等）
优点
1. 代码易读，上手快
2. 互相学习代码技巧
3. 人员互备
4. 避免脏代码
5. 有效降低BUG的出现

22. 这下小马不用失业了～
从此过上了无忧无虑的屌丝生活～

23. 提问
回答

24. 打造工具
有些重复而繁琐的工作，花点时间写个小工具替代，能够长久的方便大家工作

25. 我们想要
1. 测试，每次测试环境更新能够知道这次项目更新什么内容
2. 开发，线上环境代码报错能够知道，并且带有调试信息
3. 开发，测试虚拟机有哪台没人用
4. 开发，这个项目的运行环境手工搭建很麻烦
5. 开发，有什么办法把写完的代码自动把格式整理好
6. 产品，每周的项目数据整理太麻烦
7. 产品，很多好资料都是国外的，有什么办法看墙外信息
8. 运维，机器负载有异常随时能够知道
9. 运维，各项目能够实现灰度发布

26. 解决问题
1. 外部工具 （监控宝、日志宝、Nessus、 jsbeautifier、Redmine、GA 等）
2. 实现内部工具
3. 建立工具平台，不光打造工具，更要能够方便大家知晓有哪些工具，解决哪些问题，
怎么使用

27. 提问
回答

28. 运维生产
生产环境 , 寸土寸金

29. 面对几十台甚至上百台的服务器, 我们要考虑

30. 解决问题
• 可用性
常用方法：
定时监控：监控宝、Cacti、 Nagios 等工具
实时监控： systats、htop、SNMP、自制警告脚本等
日志记录：系统、服务级日志、应用级日志等
描述 通俗叫法 可用性级别 年度停机时间
基本可用性 2个9 99% 87.6小时
较高可用性 3个9 99.9% 8.8小时
具有故障自动
恢复能力的可
用性
4个9 99.99% 53分钟
极高可用性 5个9 99.999% 5分钟

31. 解决问题
• 安全性
常见问题：
应用级：SQL注入、XSS注入、CSRF、弱密码、网站目录可读、 HASH注入等
服务级：SYN Flood、（D）DOS、常用端口暴露等
权限管理：用户提权、访问权限范围等
常用方法：
安全扫描工具： Nessus、 Acunetix Web Vulnerability Scanner 等
防火墙： iptables、F5等
代码漏洞： 代码审计
权限控制： 访问权限定制、堡垒机、强密码、RSA动态密码等

32. 解决问题
• 生产发布
常见问题：
可用性： 停机发布、平滑发布
版本机制： 文件替换无版本、线上代码版本控制、发布及回滚
发布模式： 全局发布、渐进式发布、灰度发布
发布途径： 发布机、发布平台、发布脚本等
在线调试： 多种访问模式、获取调试信息等
常用方法：
应用优雅关闭： Nginx（nginx –s quit）等
实验室： Gmail实验室，新功能可关闭/开启

33. 解决问题
• 负载均衡 LVS、MySQL Cluster、CDN等
• 性能优化 项目-优化架构/性能分析工具、应用-性能测试、服务-优化配置
• 可维护性 标准化、虚拟化-OpenStack、同步-Puppet、自动化-自制脚本、平滑升级
• 应急容灾 单点故障、备份（软/硬）等
• 扩展性 虚拟化、数据切割、缓存池
• 容量规划 负载预期、数据监控警戒线等

34. 提问
回答

35. 利用数据
我们都是 Growth Hacker

36. 项目中的苦恼
1. 怎么样才能增加PV？
2. 新的功能是否有效？
3. 下一步该做什么？
4. 产品有哪些缺陷？
5. 处理的优先级？

37. 要解决问题？
就先要知道问题出在哪里
怎么找到问题呢？
收集 整理 分析

38. 解决问题
• 收集
预期获取：
预期某些数据中能够提炼有效的指定信息
收集内容：
来源、访问量、路径、时间、人群、速度、体验、负载、能耗、BUG、对手信息等
常见途径：
实验： 内部使用 / 性能 测试、用户使用测试等
数据抓取： 爬虫、搜索引擎等
数据跟踪监测： GA监测、Cookie跟踪、Apache / Nginx / MySQL 日志、应用日志等
用户反馈： 邮件、电话、面谈、打分、点评、投票、问卷等

39. 解决问题
• 整理
常见方法：
过滤、提取关键词、统计计数、分类、可视化
• 分析
常见方法：
建立数据模型、统计学、定量分析、定性分析等

40. 解决问题
• 常用工具
监测分析：
Google Analytics、AdMaster等
日志分析：
Awstats、GoAccess、Webalizer、监控宝、日志宝等
性能分析：
A/B Test、Pylot等

42. 提问
回答

43. 最重要的是, 构建文化
但是, 我们拒绝繁琐

44. 感谢 观看