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. //walle-web.io/
瓦力上线部署
部署不一定是脚本，也可以是web – 老虎
30. 小团队起初都是后端包揽，比如@猿蜗
@猿蜗?这哥们应该再把运维再全包了，走个后端全栈[阴险] – 宋明明
31. 感觉小团队不需要运维
这是我做多年运维的感受
等发现到50台以上服务器，再来运维介入
等到要上市，这时候估计乱的不行了，得找运维来保障上市时业务稳定
我感觉后台开发规划运维是不靠谱的，极少有人在开发和运维2个领域同时精通的，关注的方向不同 – platoli
32. 小团队，后端就可以干一些运维的活，但是一定要规划好，如果没有规划好，乱来，那就悲剧了
需要多向专业运维学习一些知识，一些方式 – 猿蜗
33. 我觉得开发和运维是一体的，建议最好不要切割开
其实运维的很多知识都是那些基础，很多底层框架什么的都需要关心 – 廖强
34. 今天讨论的是小团队，前期怎么搞都行，活下去最重要，业务可用性要求也不高，我的观点是不需要运维
规模大了，做法不同，亚马逊运维和开发不分，但基础设施也是有运维的，谷歌，Facebook,国内的大厂，基本都是有很大的运维团队 – platoli
35. 小团队基本上不需要运维，开发人员基本上都能搞定；规模上去了，肯定需要运维团队，来构建一些基础设施
不过也有一些牛叉团队 Instagram，不得不佩服，//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. 秒杀系统架构分析与实战 //toutiao.io/posts/tmrlke – 胡东升
3. 【架构】需求决定架构 —— 萌Mark的架构升级之路 //m.blog.csdn.net/article/details?id=50491265 – 小雨同学
4. 程序员的编程能力层次模型 https://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=405588220&idx=4&sn=b844093181700a40464affb2620b4365 – 黑夜路人
———————–
以上内容来自微信公众号 “黑夜路人技术” 微信群，聊天记录，欢迎进群讨论
进群方式：关注微信公众账号“黑夜路人技术”公众号，回复“加群”