团队的组建与小团队运维（团队组建的基本原理）

1. 组团队 还是要一开始有几个靠谱的高手 再慢慢扩 - 陆旭

2. 从零开始组建小团队，有几点感悟，1. 不能从最基础的人开始，从核心向下扩展，没有核心架构其他人也搞不出什么，2. 来的核心也要能伸缩，毕竟小团队没那么多人，一开始干的比较多比较杂一点要能接受，3. 可信赖，核心不稳安排不听这活就没法干了 - 杨恒飞

3. 先核心再基础 - 猿蜗

4. 还有一个想法 不要用第一版代码直接大量拉用户

比如前半年是快速迭代，大量改数据库 加功能

库和代码都很乱，最好重构一版再上线 - 陆旭

5. 这个时候的核心不一定要求多么牛逼的高手那么高的手也未必回来，能满足一年预期技术架构能力能承载就好 - 杨恒飞

6. 第一版架构，在运营型公司往往都是很简单的，可能都是apapche+php mvc就开始了，看群内分享的各种架构的成长几乎都是这种模式，我以前还纳闷，这些人这么比为什么不一开始就设计个比的架构呢

因为，追求的是速度，在人员有限的时候还没那么大规模的时候，那样就够了，那样才能满足速度和运营的要求。真做大了扛不住了就有钱找更多更牛的人来

一上来就各种高大上，那就是准备好烧钱的节奏吧

也不能称之为小团队了 - 杨恒飞

7. 说的再好，开始搞了还是一通乱搞的 赶时间 - 弹痕

8. 开始后，拍脑袋决定的还是很多。。 - 小二儿

9. 刚开始一些基本的早定好～可以乱～但不能太乱～～ - tree

10. 多利用一些成熟的东西，少造轮子 - 原

11. 简单可依赖 - 淘小淘

12. 得学会开人… - 粉粉的奶牛

13. 问: 有没有天天开会的。。

回: 有过，在进度紧张的时候不是人人都对进度那么敏感，每天碰进度 - 杨恒飞

14. 一开始把 前端，后台，运维都找一个高手

不要用3个 php 将就

然后弄半年乱套了 - 陆旭

15. 我觉得吧，这个题真的挺大的。首先组建团队，如果基本上是从零开始的话，那第一拨人很重要，也就是说，如何招到核心人员？刚开始没有相应的专业人员，面试也是个问题，不知道如何考察应聘的人合适不合适，特别是技术层面。我觉得，第一个人员是不是得靠人脉，找个靠谱的懂全面技术的人员，再来负责后续的各个岗位的核心人员招聘。 - 李三

16. 基础搭建很重要啊 - Jason Bourne

回: 基础搭建是很重要，但是有时迫不得已。时间紧，资金少，人手不够，只能弄一个能用的再说。 - 李三

17. 时间紧，资金少，人手不够就别干了 去打工吧[呲牙] - 陆旭

18. 创业可不是这样的。不干，只能拿点死工资。

像我现在这个公司就是，总共才几个人，也搞出一个项目了，我来了后做下来，发现那个架构是惨不忍睹啊。什么功能都堆在一起，而且Bug百出，我都戏称我是专业找茬的。但是也成了，赚钱了。现在要开始扩张了。 - 李三

19. 每一个光鲜的项目背后，都有一坨屎一样的代码。

项目初期，纯凭UI忽悠 人，等人全部来了。这时候才有钱招技术啊。。。

所以。。创业公司一定要UI好。UI好的话，用户能够忍你的一些小技术。他们觉得自己是一个有情怀的人，再说了，哪个程序没有BUG啊。他们还会因为找到你的BUG而沾沾自喜。 - 膘叔

回: 那可未必，有的项目的用户，出现了问题可是要来投诉的。不一定会因为找到Bug而沾沾自喜

而且，某些用户可管这是不是Bug，只知道你的系统有问题，不行了，赶紧给我弄好。 - 李三

回: bug 太多客户都跑了，前期不能铺太大，人少又想弄的大，问题只会越来越多。 - 原

20. 小团队运维除了自己还能有谁？

标准化，工具化，自动化是运维三部曲

如果只是改改配置，装装软件那是最基础的，应届生个把月就能搞的

国内个别开发以为会敲几个shell,改几行配置就等于devops了[呲牙] - 种树人

21. 还是要环境 . 机器不够过 面临的问题根本不一样.

至于改几个配置.我倒是想给很多开发说.你倒是给我改啊

朋友吐槽某大公司的开发

指挥 IT桌面支持 给他开发机装 mysql

我也是醉了

我认为devops 应该是 更全栈一些. 类如facebook的要求

一个公司 机器不多. devops的概念 可以砍掉运维部

机器多的公司 devops也得运维部去搞

个人看法. 可能不对

反正我觉得 盯住 监控界面 收监信息的 运维时代让其淘汰的

肯定是 开发平台 运维需要自愈能力,而不仅仅是发现而已 - @理鱼

22. 怎么说，从0到1是起步，是最有挑战的，涉猎需要范围最广的，从1—>1000起飞阶段 标准化，工具化，自动化很关键，从1000—>无穷需要每个人做螺丝钉

大部分人是走在螺丝钉的路上，喷着起飞阶段，鄙视起步阶段的[呲牙]

然而，螺丝钉最容易被替换 - 种树人

23. 我觉得，小团队里，搞服务器开发和运维基本混为一谈了

然后员工干没多久就会考虑离职，接着就进入某种死循环

招人基本招不到[冷汗] - yongsean

24. 先了解公司是什么性质的，组织结构如何，有哪些职能部门，以及公司目前和接下来的发展方向～领导的个人风格～这些了解之后就可以把握好团队组建的大体框架和构建的节奏～

已经初步构建了团队的框架且有些核心的人时，小团队的运维主要在解决人才梯度上面，具体工作的拆分目标是减少技术负债的风险～初期要以人为本逐步建立起工作模式，让新人逐步形成工作中的习惯～

再往后流程和文化的重要度和比例就会增加起来～这时候要多估计初建团队时的那些人的情绪和他们的发展方向～这时就超出这次讨论范围咯…

构建团队是个永恒的话题～小团队和大团队都需要运维～角度不同侧重点不同～ - 大饼

25. 小团队如果想发展还是需要运维吧

一个运维，一个 qa, 两个前端，两个 php

把设计给忘了[偷笑]

1个设计，1个 pm - 陆旭

26. 建议一个岗位最好配两个 - 淘小淘

27. 好项目都是运维出来的

人少也不能将就

养成开发不连线上服务器的好习惯 - 陆旭

28. 开发没权限。

我弄的简单web操作上线代码

线上的确不能给开发。分开最好

即便小团队绝对要杜绝

直接ssh

岗位是规划的。

流程也是规划的

我的建议就是。流程，和岗位规划好。一个人可以承担多个岗位的事。 - @理鱼

29. http://walle-web.io/

瓦力上线部署

部署不一定是脚本，也可以是web - 老虎

30. 小团队起初都是后端包揽，比如@猿蜗

@猿蜗?这哥们应该再把运维再全包了，走个后端全栈[阴险] - 宋明明

31. 感觉小团队不需要运维

这是我做多年运维的感受

等发现到50台以上服务器，再来运维介入

等到要上市，这时候估计乱的不行了，得找运维来保障上市时业务稳定

我感觉后台开发规划运维是不靠谱的，极少有人在开发和运维2个领域同时精通的，关注的方向不同 - platoli

32. 小团队，后端就可以干一些运维的活，但是一定要规划好，如果没有规划好，乱来，那就悲剧了

需要多向专业运维学习一些知识，一些方式 - 猿蜗

33. 我觉得开发和运维是一体的，建议最好不要切割开

其实运维的很多知识都是那些基础，很多底层框架什么的都需要关心 - 廖强

34. 今天讨论的是小团队，前期怎么搞都行，活下去最重要，业务可用性要求也不高，我的观点是不需要运维

规模大了，做法不同，亚马逊运维和开发不分，但基础设施也是有运维的，谷歌，Facebook,国内的大厂，基本都是有很大的运维团队 - platoli

35. 小团队基本上不需要运维，开发人员基本上都能搞定；规模上去了，肯定需要运维团队，来构建一些基础设施

不过也有一些牛叉团队 Instagram，不得不佩服，http://mt.dbanotes.net/arch/instagram.html - 踏雪无痕

36. 但这样白讲了，我觉得前期的代码和数据库比较重要，要做好备份，遇到紧急情况不至于很惨

还有就是安全，也是要做好备份，初期也谈不上安全，如果真有人盯上你，想搞太容易了 -

最好用云，一次ddos也就几十美元，没云真抗不住，尤其做游戏的，被打应该很正常吧 - platoli

【分享链接】

1. 【第469期】Hybrid APP架构设计思路 https://mp.weixin.qq.com/s?__biz=MjM5MTA1MjAxMQ==&mid=401581204&idx=1&sn=f8ce64fec33e9d97e0146c3d7020c53d - 培鑫

2. 秒杀系统架构分析与实战 http://toutiao.io/posts/tmrlke - 胡东升

3. 【架构】需求决定架构 —— 萌Mark的架构升级之路 http://m.blog.csdn.net/article/details?id=50491265 - 小雨同学

4. 程序员的编程能力层次模型 https://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=405588220&idx=4&sn=b844093181700a40464affb2620b4365 - 黑夜路人

-----------------------

以上内容来自微信公众号 “黑夜路人技术” 微信群，聊天记录，欢迎进群讨论

进群方式：关注微信公众账号“黑夜路人技术”公众号，回复“加群”