@manoeuvre 是比较少见，中间那两个外网IP，有可能是行为管理、流控或者cache之类的设备吧。因为你最后是被第8跳NAT的，所以在那之前应该都是你们自己的设备。

@lsylsy2 哦，sorry，这个其实没关系的，内网就内网呗。
我遇到过某通的宽带，给用户的是外网IP，用户一出去就是内网IP，一直走了好几跳都是内网的，其实这无所谓，路由写清楚就行。
因为那些设备仅仅是提供数据中转，某种程度上说，他只对相邻设备可达就行，不像提供服务，哪里都得通，而且得防止IP冲突，比如用内网IP就不行，可能就直接不出网关。

上面说的某种程度是有特定场景的哦。

在LZ的设备上，ping 10.0.0.10是可以到达的，但是如果从8.8.8.8往回ping，那可就未必路由到这里，如果有应答可就未必是这台设备了。

表达能力好差啊。。。

@lsylsy2 你是PPP拨号上午的？你看看你的IP
这个172.18.36.37是你的默认网关的样子啊，如果是默认网关，那你的地址有可能是内网IP。
也可以是外网IP直接硬路由到172.18.36.37
你可以这样，看看:
netstat -nr

缩进问题实在不行就截图吧。

validate_test我貌似没用过这个，好像是用form.valid还是什么的一个方法，我估计是验证输入类型合规性的，比如你的这个字段本来是int，但输入的是str，那他就会告诉你不对。

clean_content是得到干净的数据，比如django会把一些有风险的支付给转义掉。

我怎么感觉172.18.36.37就是你的边界路由了呢，或者是你跳了粉墙，粉墙P2P的对端。
如果是的话，那从第二跳就已经是运营商的设备了。
再过去222和61那几个都是运营商的接入，再后面的10.0.0.10，那是运营商内部的中转路由或者是汇聚都有可能，因为V4的IP资源有限，所以很多运营商自己的设备通常只要能用这种IP就用这种IP，除非IP真的多到不得了。

当然可能会带来一些新的问题，但貌似那影响很小。

不专业哦，仅供参考。

pycharm

志不同

是不是可以要求他们自己做单元测试之类的，然后附测试结果上来。

@saharabear 息怒，和谐

@mongodb 有道理，我的观点可能有一些偏差。不过如果仅看第二句话那样：“我的理解，这个问题不是运维或开发单方面的问题。”我觉得我也挺解脱，哈哈。。。
后面纯属我自己瞎扯

14？还不赶紧睡觉去？还上网？家大人呢？

靠谱，动手吧，什么也别管，做完之后你就会了。
just do it

呃···，原谅我没太看明白。
是不是想说新浪微博那样的。

但不管怎样，数据库的存在是必要的，因为他解决检索、统计和持久化的问题，如果直接通过http直接去获取元数据，给json，那是不是有权限管理和数据组织的问题？所以不能直接去获取元数据，而是需要一个应用去管理和维系数据与应用关系，让你获取到你应该获取的内容，而不应该获取的就不给你了，要也不给。

这样的话，把上面这些压力就给服务器了，而手机App这样的东西就可以傻瓜化，减轻手机的负载了。。。

哎呀，反正也没看懂。。。

网站方便看看不？
我的理解，这个问题不是运维或开发单方面的问题。
如@saharabear 所说，那是架构的事，为什么要有架构师这个岗位？因为他能协调开发、运维、业务和成本。

记得看过一篇文章，讲架构师需要具备哪些能力，讲的大多都是技术方面的，但事实上架构师还需要业务方面的能力，还有强大的沟通和统筹能力。呃···要是心理承受能力强就更牛了。

挺好，但Shell的话个人还是比较倾向在脚本前面划一片区域当变量写，毕竟脚本通常不是什么大工程。
要是python的话用过Yaml写，也写过数据库，都挺方便的，唯独XML不怎么用，感觉太乱了。

@a2z 可是如果NG都被攻破了，那就算后面用的是SSL，貌似想听包或者做中间人也不是什么太大难度的事了，比如改回源目标

Plone？