深度学习第三周神经网络

上一周(章)主要学习的是如何构建模型,梯级下降和使用numpy进行向量计算。这一周开始进入神经网络的学习。同样的首先上大纲:

  • 神经网络全景图(Neural Networks Overview)
  • 神经网络表达(Neural Network Representation)
  • 计算神经网络输出(Computing a Neural Network’s Output)
  • 向量化(Vectorizing across multiple examples)
  • 向量实现(Expanation for Vectorized Implmetation)
  • 激励函数(Activation functions)
  • 为什么需要非线性模型(Why do you need non-linear )

这一周的学习说简单也简单,说难也难。我们来先说简单的:

所谓简单,指的是这一周的课程主要是在上一周Logistics Regression的基础上加入了一个Hidden Layer的概念,即将所有的内容从两层输入输出结构,变成了三层,因此引入了$n^0, n^1, n^2$的三个层进行计算。这样做的好处是可以将模型变得拟合度更高,进一步提高Accuracy。而所有在Logistics Regression中用到的公式和方法基本沿用,所以数学本质上并不难,只是增加一个维度。

说他难呢,基本上就是因为增加了一个维度,所以derivative的所有计算方面,确实需要更多的东西了。当然这里也有一些小改变,那就是引入了activation function的概念,将原来那个在逻辑回归中谈到的Sigmoid Functoin,作为一种activation function;从而进一步引入其他的activation function,比如“$tanh$”

把这一周的内容集中在使用场景方面的总结:

对于3到4层Hidden Layer的时候

对于5到20层Hidden Layer的时候

对于50层Hidden Layer的时候

可以明显的看出当Hidden Layer提升了以后,预测拟合度就更高了,这就是神经网络带来的巨大意义

深度学习第二周课程(下)

上一章节提到的梯度下降(Gradient Decent)过程需要多层嵌套For-Loop循环。这种循环非常耗费计算资源。为了降低计算资源消耗,提升计算效率,本章节引入向量计算(Vectorization)的概念。本章的主要内容也是围绕着向量计算和使用Python中的numpy库来实现限量计算的过程。

本章课程内容目录(与本文无关):

  • 向量计算(Vectorization)
  • 使用向量计算逻辑回归(Vectorizing Logistic Regression)
  • 使用向量计算逻辑回归中的梯度下降(Vectorizing Logistic Regression’s Gradient)
  • Python的广播(Broadcasting in Python)
  • Python/numpy向量的介绍
  • 逻辑回归里的Cost Function解释

安装一下jupyter

本章开始需要进行练习,Python是必须要装的,强烈建议Python3,课程使用Jupyter,这里也提示了一下安装,不过后来发现好像用处也不大。这个工具主要是可以把Python的程序脚本和文字进行混排,方便与演示。如果从来没有接触过Python的话,可以考虑用一下,毕竟这个是课程也在用的环境。如果有一点基础的话,Python有自己的IDE工具,PyCharm,很好用直接下载就行。

安装Python&Jupyter。因为一直写Python所以这个一直有没什么大问题,但是Jupyt这个倒是头一次见,好像是一种基于Browser的IDE,挺有意思的。具体可以访问以下几个地址:

  • 安装Python,我一直用Brew install就好了
  • 安装Pip,不过因为买了这个新电脑以后就没怎么写代码,所以竟然没有Pip。这个倒也不难,随便上网搜索“install pip”,两步简单操作就搞定了
  • 安装Jupyter,没有按照web上说的用pkg包的方式,只是担心会安装额外的Python3.所以选择了通过pip命令行形式进行安装。

OK,三个安装结束,键入下面命令,直接启动Browser的界面

1
jupyter notebook

下面是标准编辑页面(竟然Hexo的asset_img可以用,好激动,但是asset_link确实不行,估计是因为marked里面escape的问题)

首界面很简单,就是系统文件夹。右上角有新建功能,可以新建一个可运行的python文件。在课程中,Andrew主要介绍了 np.dot(i,j) 在程序中对比for-loop,超过300倍的优势。笔者后来自己查了一下原因,看来主要还是回到了Python作为解释性语言本身的问题。为了对初学者友好,Python作为解释性语言牺牲了许多性能上的东西。而np.dot之所以much faster,主要原因是一句Python语言,对应的是用C写成numpy库,这个库会将输入进来的数据进行编译,形成编译后的语言进行调用。这种方法,远好于Python一个字符一个字符的进行读取,并根据语法分析器进行描述,占据了大量的时间。当然其他原因也有许多,比如借助编译可以使用CPU或者GPU的SIMD指令集(Simple instuction multiple data)进行并行计算,大大提升效率。根据文章将,numpy的效率可以是原生python的2万倍。而据说选用cpython会达到20万倍之多。具体原理可以参看知乎上的这篇文章:

python的numpy向量化语句为什么会比for快?

建立神经网络的主要过程

先来回顾一下基础算法:

For one example $x^{(i)}$:

The cost is then computed by summing over all training examples:

建模过程

  • 定义模型结构(例如输入feature的数量)
  • 初始化模型参数
  • 升级参数(Gradient Descent)

讲上述三个部分逐个建立并整合进一个叫做model()的 $function$ 里。几个简单的 $function$ 会包含的 $sigmoid$ , initialize_with_zeros() , propagate()

特别说明,关于 propagate() 的算法回顾如下:
Forward Propagation:

  • You get X
  • You compute $A = \sigma(w^T X + b) = (a^{(1)}, a^{(2)}, …, a^{(m-1)}, a^{(m)})$
  • You calculate the cost function: $J = -\frac{1}{m}\sum_{i=1}^{m}y^{(i)}\log(a^{(i)})+(1-y^{(i)})\log(1-a^{(i)})$

Here are the two formulas you will be using:

下面的Code里面用到了一些“内积”、“外积”、“General Dot”的概念。在课程中有相关的联系材料。具体参见这个解释可能会更加实在

使用numpy进行行列式乘积的计算

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
m = X.shape[1]

# FORWARD PROPAGATION (FROM X TO COST)
### START CODE HERE ### (≈ 2 lines of code)
A = sigmoid(np.dot(X.T, w) + b).reshape(1, -1) # compute activation
cost = - (1/m) * np.sum(Y*np.log(A) + (1-Y) * np.log(1-A)) # compute cost
### END CODE HERE ###

# BACKWARD PROPAGATION (TO FIND GRAD)
### START CODE HERE ### (≈ 2 lines of code)
dw = 1/m * np.dot(X, (A-Y).T)
db = 1/m * np.sum(A-Y)
### END CODE HERE ###

assert(dw.shape == w.shape)
assert(db.dtype == float)
cost = np.squeeze(cost)
assert(cost.shape == ())

grads = {"dw": dw,
"db": db}

return grads, cost

总结一下,这里建立的初始模型包括
$sigmoid$, $initialize$, $propagate$

优化模型参数(Optimization)

  • 初始化参数
  • 计算cost function
  • 通过梯级下降的方式进行参数更新并计算w和b的结果()

最近基本的梯级下降依据如下:

where $\alpha$ is the learning rate

总结一下,这里建立的初始模型包括
$initialize$, $optimize$, $predict$

整合模型

合并模型建立$model$,使用plot建立拟合线

深度学习第二周课程(上)

这是一个比较数学化的一章。本章课程主要分为两部分(数学基础 + Python编程实践)。

让我们先来看看第一部分。该部分内容重点是基于神经网络的一个基础数学模型,其中包括:

  • 二元分类(Binary Classification)
  • 逻辑回归(Logistic Regression)
  • 逻辑回归中的Cost Function(Logistic Regression Cost Function)
  • 梯度下降(Gradient Decent)
  • 导数(Derivatives / Derivatives Examples)
  • 计算图(Computation Graph)
  • 计算图求导(Derivatives with a Computation Graph)
  • 梯度下架求逻辑回顾(Logistic Regression Gradient Decent)
  • 对m样本的梯度下降(Gradient Decent on m Examples)

下面我们分部分进行一些描述:

深度学习概论

在Andy Ng所讲的深度学习课程里,第一周的课相对比较简单,基本上以通识介绍为主。课程分为了一下几个部分:

  • 什么是神经网络
  • 监督学习的神经网络是什么
  • 为什么深度学习开始受到重视
  • 三巨头中的Geoffrey Hinton访谈

第一部分,什么是神经网络(Neural Network)

看一下关于房价是如何预测的,以及什么是Hidden Unit

第二部分,监督学习的神经网络是什么(Supervised Learning)

在神经网络中的监督学习是这个样子的

针对与结构化和非结构化,还是有一定区别的

第三部分,为什么深度学习开始受到重视(Why Neural Network take-off)

一张图片说明一切

第四部分,Geoffrey Hinton访谈

这部分是一个访谈,不算是学习内容。讲述了Hinton个人的成长,学习等等吧。两个有意思的Highlight

  • Hinton本人大学学生物物理,研究生学习心理学,博士开始研修AI,这也是为什么他在神经网络能做出重大贡献的主要原因吧
  • 另一个关键是对GAN的学习,生成对抗网络方面的了解。如何在unsupervised的情况下进行学习

关于如何用Hexo书写数学符号(深度学习前哨贴)

翻了几个帖子,总算是搞定了。最主要的帖子是以下两个

在hexo博客中使用Mathjax写LaTex数学公式”
如何在 hexo 中支持 Mathjax?
描述在 hexo 中使用矩阵的方法

另外,按照Hexo文档上写的,理论上Hexo-math应该已经支持MathJax了,但是似乎用起来有点问题,不知道是hexo文档的错,还是我自己那个地方配置有错,以后找时间在研究吧。地址如下:
https://github.com/hexojs/hexo-math

还有最后要提醒一点,本次修改以后,不能用Hexo原生提供的assert方式来写作了,需要使用纯markdown模式。目前感觉良好,不知道后续会不会有什么坑。目前看这个改变不会影响之前的东西。

markdown的书写格式

这是一个公式 $E=mc^2$
Simple inline $a = b + c$.

大功告成,接下来需要学习MathJax了
MathJax一些说明
原文文档

CTO工作总结(15-16年度)--学习篇

上回留了个伏笔说:“做业务的技术原则:远景-目标-指标-做事;对应工作方法:监控-报警-处理-优化”

如果说,之前我懂得的更多是如何根据不同的业务发展节奏,搭建与之相配套的技术体系的话。15-16年度,可以说是我说是重要的一年,让我对于什么叫做“工程技术体系”有了一层更佳深入的认识。这层抽象,让我更懂得回到技术的本源去看事情和问题。从这里一层层扩展开去。

工程技术的本质

我最近特别喜欢在技术前面加上工程两个字。因为这些年的工作我其实经历了一个去工程化的过程,那就是太多的人开始说到互联网,说起研发开始弱化工程师这个概念,更多的是在突出“技术”这个说法。但正是对“工程”的弱化,让我们在很多时候忽视了从传统工程领域借鉴经验的机会。事实上,传统工程和如今的IT工程确实存在区别,但本质上,作为工程化理论,就永远摆脱不了一个话题:一个关于“质量”和“速度”之间永恒的矛盾。如果细想想,对于每一个Tech Lead而言,其实就是在不断的针对这两个问题进行抉择和平衡。没有什么需求是真的做不出来,只是怎么做,才能在质量和速度之间寻求一种平衡。我们知道,在相同产能条件的情况下,

  • 第一、质量越高,要求的精细度越高,对应生产难度也就越大,速度也会因此而降下来。人不是机器会疲倦,会出错。
  • 第二、而如果对生产速度要求较高,那么质量的下降往往不可避免。但是可以大大提高产出结果
  • 第三、虽然是最后,但是很重要,那就是长期低质量对产品速度必然产生负面影线。

由这三点,演化出来一系列方法和理论和话题。我在这里把“质量”与“速度”的矛盾叫做“工程技术本质”,以说明它的地位不可撼动性。

针对业务的技术原则

那么既然Tech Lead们需要不断解决的是“质量”和“速度”的矛盾问题。于是乎,这里面就衍生出一个很有意思的话题—如何做技术决策,如何判定自己的决策是合理。在我的这个理论里,若要做好这个决策,第一部分就是要了解业务。可能这对许多人来讲不可理解,作为技术人员,我做好自己的事情就好了,为什么要了解业务呢。这件事源于以人为中心的互联网模式。随着物质的极大丰富,供给模式,从最早的粗放型生产、分销、渠道,转变通过网络快速的寻找人的需求,根据需求进行快速迭代演进从而精细化的扩充人们在某一个或几个点上的消费习惯。在探寻过程中,其实对于互联网业务来讲,就是不断的实验过程。既然是实验,那么快速看到实验结果和实验深浅的把握就显得尤为重要。所谓实验结果,就是“速度”,即越快速度看到结果,越好进行决策是更进一步实验还是改换新的方向。实验深浅,对于技术而言就是实验的“质量”

那么作为每天坐在IDE前面思考代码和逻辑思路的技术人员而言,我们无法接触真实的用户,没有时间思考和观察用户在干什么,如何才能有效的了解业务呢?我把技术人员了解业务的方法分成了四个基本过程:

  • 远景,大多指一个业务长远的,或者一段时间的方向性目标。远景的很重要,它是指导一切的原则。当然,对于一个大的业务方向来说,形成商业收支目标是核心。但是拆解下来,不同时期,对于形成收支目标的要求不一样,有的是有也不一定是要在财务上展现。比如作为如今的滴滴,当下的最大远景就是实现盈利,但是对于在Nasdaq上市的京东而言,快速增长可能比盈利更重要。作为一个公司而言,远景往往和公司的核心管理人员以及投资人的想法相关。但是,对于一个业务的远景,往往会小许多。比如病历夹工具业务线,他当下远景就是用户活跃的持续增长。所以,绝大多数功能让用户有更强的黏着性。

  • 目标,通常和当下所做的工作直接相关。为了实现远景,任何的业务都会拆成几个小步工作。那么目标,就是每个小步要完成的结果。这个结果可能是让用户在上传病历过程中使用不会产生疑问,也可能是让用户更快捷的在医口袋中搜到药品。作为每一个小步而言,多数业务会设立唯一的目标。当然如果优化功能都比较小,也不排除建立几个目标的可能。目标往往是团队的负责人做的定义,但是对于远景的优化角度不同,思考方式不同,小步目标也不一定是单一的。在互联网的实际环境中,目标也是可以被拿来讨论的。从这里开始,有兴趣的技术工程师,便可以参与深入的讨论。

  • 指标,既然订立了目标,就一定要寻找可以进行衡量的目标完成好坏的指标。我们拿“让用户在上传病历过程中使用不会产生疑问”这个目标来说,这里可以建立的核心指标是“用户上传病历数增加”,这是核心业务指标。分解下来,可能还有一些其他指标,比如上传服务器反应时间在200ms以下,上传成功了70%以上等等。做任何一件事情,都应该是可衡量的,没有量化的工作,就是刷流氓好么:)。定义指标的工作,需要技术工程师的重度参与,这里包括订立那些指标,以及如何将指标反馈给BI系统或者其他数据报告系统。这一点非常重要。也是后期业务、技术团队跟踪做事好坏的核心。

  • 做事,在了解远景,目标达成一致,以及订立好合适的指标后,大家就要开始基于指标工作了。那么指标从某种角度上讲,就是质量的衡量方法,这个一般说来,叫做质量底线标准。任何的速度,在底线标准前,都必须服从。而做事,就是考虑,如何在保证质量的基础上,尽量的提升速度。这里就是Tech Lead们的专业技能体现了。具体的方法有很多,比如XP,Scrum等的工程实践,比如新技术的引用提升研发效率,再比如团队的文化气氛等。

总结一下,技术工程师,Tech Lead都很难真的完全深入业务细节去思考逻辑关系和用户使用习惯。但是经过以上的四个步骤,可以大体梳理每一个小步的背后的逻辑,并通过一系列指标进行有效的质量监控,用一系列工程方法指导做事,提升速度。

针对工程的技术原则

上面谈到了做事,谈到了比如工程方法、新技术的引用、团队文化等,那么针对技术工程,是不是可以衡量呢?答案当然是肯定的。任何工作都应该是可以衡量的,只是指标不同。这里我总结下来还是四个步骤:监控-报警-处理-优化

为什么要衡量?

在解释具体工程上的四步方法之前,先解释一个问题。可能又不少人会问,为什么你总是说衡量。看看我说的做事顺序,其中最后一步叫做“优化”。人类进行工程实践可能有几千年的历史了,很难说哪些事情是没有干过的。但是,问题的关键在于,对于每一次“质量”和“速度”博弈的实验中,如何进行优化,才是人类和动物最大的分别。我们在不断积累经验,寻找更好的方法。这就是实验的本质,也是任何事物前进的源头。“做事”的方法许多,根据团队、实践、节奏、个人知识能力等等不同,有太多的优秀实践可以应用,但是哪种是最好的,只有在指标定一下进行有效优化,才能得到越来越好的效果。所以下面说的四步,不仅仅适用于业务开发,也适用于技术工程人员对一切问题的抽象解决方案中。

  • 监控,在针对业务的技术原则中,我们说到了指标。我们说技术人员要深度参与指标的定义,并做好指标的数据向BI或其他数据报告系统反馈工作,这就是监控的一种,主要应用在业务的指标监控中。其实,针对技术本身也有一系列的可以做的监控指标,比如线上Bug的数量、Crash率、服务器Apex指标,应用可用性等等。但是这里需要需要特别注意的是,在我看来,监控不是目的,是为了解决问题而存在的,特别是解决上面说的业务目标。比如有段时间业务目标是满足双11的客流访问量,那么Apex、网络带宽、负载均衡的资源使用这些就是重要的监控,可能需要秒级别的信息收集。那么这个时段,其他的比如CPU数量、客户端Crash率、网页兼容性,在这个目标面前,就不需要被严密监控,可能是天级别监控就可以了。所以监控是分级别,也是分时段的。
    人曾经问我,我是一个Android起家的Tech Lead,对于iOS、Java服务端,我不是很了解,要怎么才能做到很好对团队工作进行有效的带领和优化。这里我想说,通过指标监控,就可以达到目的。与相关的Tech Lead讨论针对特殊目的而细化的监控指标。

  • 报警,许多人谈论监控,更多的是一套漂亮的报表,线图、饼图、柱图、箱图各种上。这是我以前常犯的错误,以为报表意味着监控。其实,在过去一年,我学会的最重要的知识就是,展现的目的更多是为了给别人看的直观,用以表明优化的成果,是一种回朔和预测型的工具。但是做事的时候,却不应该作为工具,回到计算机或者生物的本质上,0和1才是我们认识事件最直观的方法。因此,报警在我看来是工程监控最有效的手段(工具)。这种被动式相应能够大大加强响应效率和工作效率,根据响应的情况再去寻找相应的报表或者内容数据进行分析,从而得出有效的处理方案。
    设立报警的过程本身并不难,最难的是适当报警阀值的斟酌。太高起不到监控的效果,太低虚报误报使得报警无法有效应用。这个时候需要对技术有比较深入理解,对不同阶段对应指标有比较深入理解的技术人员(这里就不是一个纯工程问题,而上升到技术本身能力上),对报警阀值进行准确的把控,并持续优化。

  • 处理,这块儿没太多可说的,这是每一个工程师的老本行,根据报警问题,使用数据综合分析,数据不全可能需要进行场景复现,如果是紧急问题可能还需要采取紧急方案、备份方案、临时方案等进行解决。总之是确保报警状态恢复到正常的水平。这个时间会根据不同业务和级别的不同,处理时间也会不同。

  • 优化,最后来到了前面说的,工程技术原则的核心,就是优化。前面说到互联网的最大特点就是实验,不断的、快速的实验,了解和提升用户的体验,帮助用户解决问题。所以,无论是对业务指标的优化,还是技术指标,或者别的什么指标的优化,总之优化是技术工程师做事的终点,也是新的一轮工作的起点。研发工程由此不断迭代向前,帮助解决一个又一个业务目标。

最后做个总结,在过去的一年里,对于上面方法的理解和应用真正改变了我将近十年的认识。过去的我,一直在学习,学习各种技术、学习各种最佳时间、学习各种方法论来解决一个又一个的研发问题。记得刚进微软那会儿,我的最大收获是如何通过互联网快速解决问题,把Google用的炉火纯青。在英国的4年里,我明白了从0到1的建设过程和研究方法。ThoughtWorks的3年让我懂得什么叫做研发体系和最佳实践。如今,在杏树林,很高兴能遇到一群志同道合的人,至少现在吧,感觉自己的理解又上升了一个新的高度,实践因什么而存在,要解决哪些问题,如何才算真正解决,解决问题的为了什么。这是我2015-16年度,最有收获的部分,共勉。

Lesson & Learn

2014年,让我引以为自豪的是学会了“运营是中国互联网的核心”
2015年,让我引以为自豪的是在不懈的努力和好友的陪伴下,组建了“JS端团队”,让杏树林称为具有一线互联网技术的公司
2016年,希望我可以让数据驱动彻底称为公司的基因,try my best!

一些具体做大事儿的历史记录:

2014年:

  • 产品2周迭代化(发布数据)
  • 病历夹Crash问题实现完全可控(umeng数据)
  • 开发自动化(持续打包和发布)
  • 口袋/文献/病历夹APP产品数据可还原化(每个月的全部流量数据)

2015年:

  • 产品目标的数据化(让迭代更能拥有反馈)
  • 产品客户反馈的及时列表
  • 将迭代测试时间从5-8天缩短到3天
  • 运维的自动化(功能运维中ssh比例)

2016年:

  • 运维体系化(DevOps发展,产品团队自运维)

CTO工作总结(15-16年度)--工作篇

通常我会在每个年中对从上一年的7月到这一年的6月的工作做一个总结。主要原因是年终的时候大家都在总结,但绩效、年终奖、年会、圣诞、新年等等,其实是一年中时间最紧张的时候。我不喜把事情都堆到一块儿做。刚好英联邦的财年就是年中,所以索性就选了这个时间做总结。

本次总结分成两大部分,第一个是工作篇,主要陈述上一个总结中的预期工作在这一年里的开展情况和变化情况。本次总结多增加了一个学习篇,主要是觉得进入创业中期的工作状态是日新月异,学习到的东西越来越多,而不知到的东西也越来越多。希望通过总结暨给自己一个交代,也给未来一年一种鞭策。在一个创业公司,如果你的成长速度慢过于公司,那就坐等淘汰。

工作篇

一般来说,我对CTO的工作理解都会在我的xmind里面不断增加,也会根据实际的公司运行情况做优先级的处理。下面的总图基本反映了我各部分工作优先级预期和状态。其中数字代表在15年6月份的时候我对这几部分工作的优先级安排。而脸谱代表了对所有工作我现在自己看来的满意度。作为一个overall的评价来说,我觉得还是挺满意的。尤其是在商业战略、团队、研发和技术团队运营这几部分。

对于用户,这一年碰的主要是一些企业用户,大体有所了解,更多的接触还是间接的,通过销售或者面试过程中谈话。医生用户几乎没有接触过。所以这块儿我对自己的工作是相当不满意的。任何事情不站在前台需求的角度,即使我现在有了数据的武器,也不会产生全面的印象和理解。在品牌塑造方面,写了些文章,但是感觉效果不佳,无论是传播力度还是广度并没有达到我预期的效果。

下面会针对每一个做逐一分析。

  • 先从优先级最高的商业战略开始。这里在新的一年我改一下名字,应该叫做技术战略,是指应对公司发展需要而做出的技术类总方向的决策。之前预期这一年的三个大事儿基本上都做了。

    第一个是安全管理,这块儿在15年的下半年里,引入了安全宝的安全审计,做了渗透测试,确实发现了不少问题。服务端和运维一起最终将安全审计出来的问题,一一解决掉。让杏树林在安全防范上迈出了一个小步,但同时也是安全体系化的重要一步。接下来的安全工作出过一次事故,但是主要原因不是技术本身的安全隐患,而是出现在业务上的密码过于简单而产生的暴力破解。根据这个,对公司的VPN网络,请求时间间隔,各个系统验证码服务做了升级。接下来一年这一块儿肯定还是要做,但是可以从安全管理,上升到安全体系的高度,对一些安全工作进行常规化管理。

    第二块儿是团队的结构化。终于在杏树林走到50人技术团队的时候,我们迎来了业务化改造。这是我一直希望的事情。在我看来,一个团队,若想保持高效的战斗力,必须团队数量足够小,团队关注点足够专一。只有这样,才有可能把事情打透,把业务做到底,所以我在年度之初就策划了这个改革,好在的是,我们的COO也足够给力,快速的推动了我的改革。让我这个目标得以实现。

    第三块儿是核心技术能力的建立。这里包含了纯工程技术能力和基于业务的技术能力两大部分。纯工程是对原有公司的技术升级。包括了JS大方向的引入,Docker化和AB测试。但是很可惜,AB测试并没有完成,我觉得原因有两个,第一个是如果做AB测试,工具是一方面,但最重要的另外两个方面是基础数据,还有业务需求。这两块儿目前都在建立之中,随着数据驱动的演进,杏树林开始有计划的加功能,减功能。AB测试的需求正在起步,但是在过去的一年,因为数据驱动不到位,所以这部分没有太多需求。所以,这块儿掌握的一个核心是

    只有有了数据驱动,才有AB测试的需要

    另外,除了工程技术外,业务技术当时15年中订立的是OCR的核心技术能力,以及数据结构化。前一个OCR能力基本上已经形成规模,有人持续为之进行优化。后一个数据结构化目前并没有很好的方法,这也是新一年的重点工作。在去年数据结构化里,学到的重要教训是,数据其实本来不需要结构化,关键是有效的检索和回馈。因此搜索引擎,将会成为新一年工作重点。

  • 优先级第二的是R&D,研发体系,无论何时都是技术研发的重点部分。基本上当时的计划都完成了。公司从一个对技术仅是零散开发,到如今有了比较成型的各方面技术研发体系。新的一年,研发体系会往基础架构方面进行比较多的拓延。通过公共服务体系持续提升研发能力。但是这块儿,其实很多公司干得并不好,至于我们能不能,拭目以待。

  • 同为第二优先级的是Client,这里其实是一个对用户和客户的共同说法。15-16年度,主要的工作在客户那里。15年下半年做了最重要的事情就是云学院产品的研发,经过内部产品和外部销售的反复沟通,完成了第一版云学院的基本体系和工作方式。从此云学院摆脱了无形态,minisite各类的方式,开始往产品化方式发展。但是在用户方面,确实没做什么,这部分将会作为接下来工作的方向

  • 第三优先级的是品牌建设,这块儿这一年里花了不少时间。写了前后10片左右的文章,但是文章覆盖面主要是医疗这边,更加偏向于给行业和VC这类人看。但是并没有起到很好的作用。品牌建设的核心应该是面向技术人员。所以,接下来的思考是将之前类的文章数量降下来,像“大数据分析报告”这类的对企业具有一定价值报告。还是考虑在技术类演讲上增加曝光度,并且把团队加入进去。

  • 第四优先级的是团队,这里团队之所以被列为较低的优先级,主要是因为一个相对完整的体系已经建立起来。大家可以看看作为参考吧。我觉得以目前团队的规模,短时间在超过100以前,这套体系应该不会有大的变化。还有一个最关键的,不想做大团队。坚信小而精的团队才能爆发最强的小宇宙。

  • 最后的部分是团队运营。团队运营主要指的是一些和基础财、物相关的工作。这一块儿属于维持,本来的工作就不是重点。主要是在流程上做了一些努力,其中包括了线上事故和Bug的处理流程,这部分对公司有一定的影响。

学习篇

埋个伏笔吧,上关键词,“做业务的技术原则:远景-目标-指标-做事;对应工作方法:监控-报警-处理-优化”

ISO27001工作记录之一声叹息

因为要和许多中国/国际企业合作,我们需要一套更加完备的信息安全认证。所以这两个礼拜搞ISO27001搞的很心烦,于是写写27001的概念,顺便聊聊认证体系。

  • 关于ISO27001:

    ISO27001认证,由英国标准协会(BSI)于1995年2月提出,中文全称《信息安全管理实施细则》(BS7799-1:1995)。它提供了一套综合性的、由信息安全最佳惯例构成的实施细则,目的是为确定各类信息系统通用控制提供唯一的参考基准。1998,提出了第二个部分,中文全称《信息安全管理体系规范》,它规定了信息安全管理体系的要求和对信息安全控制的要求。2005年被ISO国际标准化组织采纳,形成了ISO/IEC 27001:2005。完整的ISO27001包括了11个方面、39个控制目标和133项控制措施。是一个不折不扣让一个互联网人晕到吐血的管理制度。主要11个方向包括:

    1. 安全方针
    2. 信息安全组织
    3. 资产管理
    4. 人力资源安全
    5. 物理和环境安全
    6. 通信和操作管理
    7. 访问控制
    8. 信息系统获取、开发和维护
    9. 信息安全事故管理
    10. 业务连续性管理
    11. 符合性

    通过对整个ISO27001这11个方面的落地,实现一个ISMS(信息安全管理系统)。这里特别说明,这个系统不是互联网概念上的系统,指的是一个体系化的东西,包括了上面所属管理、行政、人事、信息技术等各个方面。详细的就不在这里说了,实在是好多。目前这个工作已经在做了,这里给大家看一下我们的列表,这里面大概60%是技术团队要做的。

  • ISO27001与HIPAA

    之前有不少人问HIPAA的事情,现在估计也会有不少人问ISO27991和HIPAA的区别。所以这里简单说明一下。从概念上说,ISO是一个标准,可以由相关评级机构进行评级,办法符合标准的认证证书。这个证书可以用来和企业进行合作,以表明我司在信息安全方面的准备和能力是充分的。而HIPAA是一个法案(也可以说是一个法律),就是每个医疗相关企业遵守是必须的,不遵守如果被举报就要吃官司。哦,对了,这里还要特别说明,ISO和医疗无关,HIPAA是专门为医疗信息保护准备。所以ISO主要讲的是信息保护这个系统工程要做哪些和怎么做;而HIPAA虽然原则上提供了一些强制性的标准和工作方法,但是其核心内容更加强掉哪些信息是禁止泄露的。

    所以说,本次公司的ISO27001认证,我们也是请了相关具有评估资质的公司来进行评审。

  • ISO27001我们所做的和下一步需要做的事情

    下一步主要要做的事情就是完善文档和制度了。这里我想特别说明,之所以我会很重视这件事情,不是为了完善文档和制度,反而是从一个专业技术的角度,想想怎么从里面尽可能找些方法,避免繁琐的文档和制度。在我心里,过于完善的制度和方法,对研发和快速迭代,快速试错本事是有害的。所以,尽最大程度的减少ISO27001对互联网团队的伤害,是我最近想研究的一个话题。有了结果的话,可以再写一篇博文了,呵呵。看一下一片标准的ISO27001文档的样子,像下面这种文档理论上是每次都要写的。做过企业软件的人,应该知道。

总之,ISO27001确实是一个挺麻烦的东西。但是,从企业合作的角度,又不得不去做,并且也可以成为公司系统安全方面比较好的一个PR背书,从这一点上看,质量体系的工作比HIPAA的工作实际上在中国更有公信力。所以吧,对于我来讲对于这东西属于虽然很反感,不屑,但是又知道很有用,不得不去做的东西。希望看到文章的技术兄弟,也是对此表示一种尊敬吧。我自己承认,了解还是有必要的,只是要做多少,大家根据实际情况做到心中有数就好。