企业设计物联网设备时必须确保能够设备正常工作，并遵守成本和美学考虑因素制约。以下是企业设计物联网设备的一些其他考虑因素：
电池寿命：Wi-Fi设备公司Edgewater最近支持在Kroger商店内部署物联网，而Edgewater首席执行官AndrewSkafel表示，电池使用寿命是最重要的设计因素之一。他指出，在杂货店里，有数百个传感器监控食物冷藏状态，“因此，额外多年的电池续航时间可为他们节省大量成本，我知道这是他们设计的前沿和中心。”
网络连接选择，在这一点上，有一致意见：在涉及物联网网络连接时，将不会达成共识。
芯片巨头ARM的物联网产品经理MikeEftimakis说：“没有一种标准可以统治世界，这可能需要不同的解决方案，不同标准的组合，实际上，我们经常谈论无线技术，但我们不应该忘记，物联网很大一部分也可能是有线连接的。”一些专家说，网络连接实际上很容易选择，因为企业的业务案例可能很清楚短程或远程技术以及许可或未许可技术的选项是否最合适。企业也可以在物联网部署中选择多种连接技术，而不仅仅只有一种。沃达丰的《物联网晴雨表报告》就发现，即使是大约100台设备的小型部署，也通常依赖于三种网络连接方式，以确保他们想要的弹性和覆盖范围。
环境：设备需要在极端高温或低温下工作吗？抵抗振动？它可以插入电源或者必须依赖电池？在企业自己的网络上运行，还是在别人的网络上运行？思科物联网产品营销、战略主管TereaBui说：“设备部署环境的稳定性是其设计的重要因素。”她指出，在办公楼内设备与石油天然气或采矿设施设备之间存在巨大的物理差异。
应用：应用程序开发可能主要是软件的功能，但它在所需的处理能力和内存以及设备必须与其他设备或云进行通信的程度方面也具有设备含义。Kirkland物联网首席架构师詹姆斯柯克兰表示，红帽正在将物联网转向开源，就像云生态系统一样，因为维护自定义堆栈既太昂贵又难以管理。
应用程序还需要具备可拓展性。对于一些企业来说，几十年来一直相同的一些后端遗留服务最终会成为一个阻碍点，公司不知道如何扩展，或者无法扩展。这些应用程序具有很长的使用寿命，为企业提供服务意味着企业需要扩展设备支持。
部署：物联网设备的物理设计必须考虑其部署速度和成本效益。对于小规模的试点而言，这似乎不是一个重要因素，但在进入大规模市场的过程中，这一点至关重要。对于物联网而言，将设备置于成千上万的“东西”上所需的人力资源可能影响外形和部署成本。你需要从设备本身思考如何完成这件事，一个设备能简单地粘在另一个物体上吗？它需要插上还是拧上？完成一次安装需要两个小时还是10个小时？需要什么样的水平技能？而且你要做的一件事是，一旦你部署它，就再也不要碰它。
运营费用：物联网新手普遍忽视的一个问题是，一旦部署在现场投入运行，运营成本就会很高。这些成本包括网络传输，但也包括远程设备的支持成本，从一个地区的几千个到几个区域的几百万不等。公司需要考虑如果未按期完成部署的成本，例如，如果部署需要花费6到8个月时间，结果拖延到12到18个月？这意味着几个月收入的损失；设备的部署环境也会影响支持成本，比如访问设备的难易程度。运营成本的第三个方面支持部署所需的团队规模，以及解决一级和二级问题的速度，尤其是在一家公司打算跨多个地区大规模启动的情况下。
设备生命周期：当一家企业急于创建物联网设备并将其投放市场时，安装部署可能是优先考虑事情。但是ArrowElectronics物联网平台和服务副总裁AshishParikh指出，为了实现全面的物联网设计，如何“负责任地和可持续地将设备从服务中移除”的问题是长期规划的一部分。
大多数人都不谈论这个问题，他们都会说，“我必须把它拿出来。”但是，如果你有500亿台设备，那么所有的电子设备会发生什么？设备上的客户数据会发生什么变化？这些设备需要在5年或10年或15年的生命周期结束时退役。这些问题仍然需要设计者考虑。

　　	人工智能、大数据、云计算和物联网的未来发展值得重视，均为前沿产业，有兴趣的朋友，可以查阅多智时代，在此为你推荐几篇优质好文：

1.物联网智能化产业的现状、趋势与发展

http://www.duozhishidai.com/article-13649-1.html

2.物联网技术，主要应用于哪十大行业

http://www.duozhishidai.com/article-13983-1.html

3.生活中我们常见的物联网应用有哪些

http://www.duozhishidai.com/article-12998-1.html

多智时代-人工智能和大数据学习入门网站|人工智能、大数据、物联网、云计算的学习交流网站

Mac在企业环境中的管理瓶颈(2)
－活动目录(AD)集成
注：Mac在企业环境中的管理瓶颈(1)

 
前言：

      前面说了关于平滑迁移的一些想法，这次想说说在企业应用中最最关键和基本条件的，AD集成问题。这个话题很不好说，因为AD集成不仅是最重要的一个企业应用的瓶颈，它牵扯的方面很广，目前这方面应用的讨论最多，问题也最多，深入探讨涉及很多细节，广泛讨论又是涉及诸多方面，总之我一个人不可能把AD集成方面的话题说得周到和详尽，难免有遗漏和错误，不过想到最初“抛砖引玉”的目的，也就放下了包袱，放手写写自己的一些认识和感受吧。
 
      目录服务是当代企业信息资源管理必不可少的一个手段，而在现实的企业环境中，作为事实上的业界标准和应用最广泛的活动目录(Active Directory，简称AD)，是不能被忽略的。AD是微软占据企业的拳头产品，微软的所有企业产品，可以说都是建立在AD这个基础之上的，而且是原生地
支持AD，AD在实际企业市场中也占据着不可忽视的主导地位。Mac的产品要想进军企业应用，不可避免的要面对和AD集成的问题。
      苹果有自己的开放目录(Open Direcory，简称OD)产品，也是目录服务的一个实现版本，它是Mac OS X服务器操作系统中的一个基础架构，AD和OD原理上是同源的，都是目录服务，他们面对的对象和具体的实现的区别，不能彼此简单地统一，所以苹果在面对企业用户的时候，必须和AD友好相处，艰难的选择是：即不放弃OD，也要和AD集成。
      目前来说，Mac系统原生地支持OD，可以和自己的OD很好的相互紧密结合，这正如Windows和AD的默契一样。同时，Mac系统可以很好地支持多种用户认证手段，所以也可以实现对AD认证的支持。单从认证方面来说，与Windows产品的对比来说，Mac系统具有更好的可扩展性，但是可扩展性好不是说用户体验就愉悦，相反，灵活性会产生更多问题，这些问题有的时候会另系统管理员甚至是用户感到沮丧，这也是我要说它是最重要的一个瓶颈。
 
开放目录服务OD
      使用OD提供的目录服务，可以对苹果系统进行全面的管理，它的管理是通过一种叫做MCX(Managed Client for Mac OS X)的技术来实现的，MCX都是以XML描述语言来描述、传输和存储的，可以是加密的也可以是明文的，无论什么形式，都是Mac系统原生支持的，其实这个和它的系统和应用程序的配置文件的管理方式是统一的，它的这个实现，和Windows里面的通过Registry Keys和ACLs(Access Control Lists)的组策略(Group Policy)相比较，是完全不同的，相比较MCX更容易理解和实施，当然，Mac系统也是支持文件级别的ACLs，只不过不是原生的，有的应用是就不支持或者不完全支持ACLs。
      OD提供管理员以相当的自由度和深度来管理网络资源，比如对系统的行为和用户行为，用户可以使用的系统资源，应用程序，界面等等做出详尽的安排，但是面对大型企业的复杂管理规范来说，就没有组策略那样的灵活性了，所以，这也是为什么OD只能适用于工作组级别的一个原因，同时OD也无法对PC进行方便管理。
 
Mac和AD集成
      Mac系统自带一个叫做AD插件的认证组件，与它的LDAPv3等其它认证组件类似，来实现和AD的集成，通过用户验证并准许用户登录系统，也提供网络用户，本地用户和移动用户的功能，以实现对不同用户和应用场景的支持，同时可以把移动用户的本地数据和服务器之间进行同步。它也支持Kerberos网络认证协议，获得Kerberos钥匙，以实现对大部分系统资源的Single-Sign-On（一次认证，简称SSO），也就是用户登陆后，在访问其它网络资源的时候不会再次询问用户密码，而自动通过内部机制确认用户的访问权限。
 
      由于Windows AD对一个网络资源使用SID来标识，而基于BSD（类Unix）系统的Mac，对于用户和用户组需要一个唯一的用户标识UID和组标识GID，他们之间没有对应，在实现AD集成的时候管理员可以选择使用一个AD属性来作为用户的UID与Mac，叫做静态UID，如果让系统自己生成一个ID的方法，叫做动态UID，动态的问题是，用户每次登录都使用不同的UID，管理员要进行必要的处理，否则会造成访问权限的混乱。
 
管理Mac

      通过上面的简单集成到AD之后，如果你的企业决定对Mac系统进行一种松散的管理，那么只要实现了利用AD对用户登录认证就可以了。如果需要实施如同对PC的管理，管理员就需要进行进一步的配置。目前有大致三种有效途径，实现类似于AD里面GPO的管理效果，当然还是使用MCX来实现具体的管理功能。下面我们来粗略地介绍：
AD架构扩展：

       这个方式也是苹果官方推荐的方法之一。自从Windows Server 2003发布以来，管理员可以自由地对AD架构进行自定义的扩展，Mac也是通过这个方式，来让AD来认识和管理Mac系统。通过把36个属性和10个类添加到AD架构里面，AD架构就可以实现对Mac系统的“完全”控制，管理员只要使用苹果的管理工具Workgroup Manager，就可以实现如同在OD中一样的对Mac客户端的管理。如果你的系统需要这方面的支持，请购买苹果的服务有苹果的专业人员可以帮助你实现这种扩展。

       它的问题是，首先，你的AD架构很可能不被准许变动，你的AD系统管理员或者安全措施不能接受这种变动。任何对架构的变动，可能会对其它产生不可预知的影响，而且以后的支持工作也是无法预估的；其次，苹果没有保证未来会如何变化，随着版本和技术的升级，难免未来要做变更，那么这种变更对系统架构来说一种不可预知的，你的系统可以接受嘛？系统升级后，不同系统版本的同时存在，产生的他们之间的管理差异的解决也将是一个可能面对的技术问题，这些将在以后的技术发展过程中被一步一步的重视。

双目录服务：

      也叫做魔术三角(Magic Triangle)或者金三角(golden Triangle)架构。上面的方式，使用单一的AD目录服务实现对客户端的管理，而这个双目录服务的方法是，把OD服务器集成到AD里，用AD用来实现用户认证和取得用于认证的Kerberos钥匙等, OD实现对客户端的管理。

      安装一个Mac OS X服务器，并把它添加到AD域中，使它称为一个域成员服务器，并让客户端首先到AD上取得用户认证，然后再到这个苹果服务器上取得用户和计算机的管理信息。这样，同样可以实现对客户端的管理。具体的实现方法在以前的Blog里面有专门的一个翻译系列讲述。

      这个配置需要另外的硬件和软件，而且备份以及用户数据同步等等，都可能会成为实施中的问题，一个专门的Mac OS X Server管理和维护团队可能也是必须的，这是软成本的付出。

      两个Security 
Database是必须面对的，如果你的企业对于Security的一致性要求特别高，那么两者的不一致会带来管理的障碍和困扰。当然，安全的一致性在不同的操作系统中的体现，本来就是有其内在的差异性，所以过分强求一致性，在现实中是不现实的。

      而在面对大型用户或远程办公环境的时候，这种方式的规模适应性和可延展性，以及当地部门管理员的培训等，可能都会是一个成本问题。

第三方支持：

      现在第三方插件有为数不多的几个，一般来说，他们提供一种这种的解决方案，它即不变更AD架构，而且让管理员一个熟悉的GPO管理工具，来同时管理两个平台的计算机和用户。有的使用插入中间件的方式，提供一个管理环境，比如Centrify，有的是安装插件在AD上以及提供MMC插件(Snap-In)，比如Likewise等。

      在决定使用第三方插件之前，需要做足功课，目前的可用软件并不多，而且可靠性、排错、技术支持、公司的发展稳定性等等也是一个头痛的问题。
 
人才储备

      面对Mac系统在企业中的管理，企业一定要进行人才的培训和储备。比如下面可能是对合格的Mac管理人员的一些要求：
熟悉*nix，熟悉Mac，一定要有CLI的经验和知识；
最好有Apple的认证；
实际经验，尤其是在解决问题上面的能力，要有debug的能力；
      Mac的知识获得还是比较窄的，主要是从苹果官方获得，在线资料和在线论坛，求助苹果技术支持团队的协助，而第三方的技术支持公司还是比较少见，网上的资源也不多，而且技术水平良莠不齐。这样的状态的好处是可以集中精力，坏处是人数不够多。而且从现在的情势看，Apple的精力主要实在消费产品上，那是企业利润的主要来源，而且源源不断，所以它的主要注意力不在企业上，这个是一个重要问题，不过随着Mac系统在企业环境中的应用的增多，苹果公司必须面对这样一个事实，采取更积极的步骤来增加对企业应用集成的比重。
 
苹果本身的问题：
      前面也说了一些，这里就再补充几个。
企业级技术支持部门不够强壮
在线知识库，不人性化：搜索功能虽然强大，但是由于结果过多，不容易找到真正的，混乱：没有分门别类的知识库
网站速度也是不快
硬件系统不开放，造成硬件成本太高
系统更新和修补反应不快
 
版权信息
: 本着开放交流的原则欢迎转载，除非明确声明"谢绝转载"等字样. 


所有文章/图片/代码(除转载和翻译)，版权均属文章作者


.

转载请遵守下面规则:

 1）保持文章的完整性； 2）不得以盈利为目的； 3）完整标注文章作者［Tony Liu@中国在线教育
］和文章中标注的所有版权信息。

其它事宜，如:需要商业用途或以盈利为目的的、或者部分转载的等等，请与本作者联系: TonyLiu2CA@yahoo.com



其它技术问题：

下面说说一些技术上可能遇到的小问题。
网络和AD负载加重

：
      使用Mac的AD插件工程中，可能会发现，AD服务器的负载会明显加重，首先Mac会频繁地访问AD服务器，造成很多的AD访问和网络负担，尤其是当使用网络用户的时候，对于网络的负担会比较明显。
 
SSO：


      它不支持所有网络资源的一次认证功能。
 
钥匙链的困扰:


      钥匙链（Keychain）是Mac系统本地存储和管理用户密钥，系统密钥等等机密数据的一个内在机制，这个机制在单一的Mac环境中工作的相当出色，为用户提供了极大的便利。但是在多架构的环境里，却成为了最终用的一种噩梦。
      它的机制是，使用用户的登录密码加密钥匙链文件，并在用户每次登录的时候打开它，推出登陆后会自动的关闭。打开后，里面储存的密码就可以被用户的应用程序使用，比如Safari可以存取用户用户名和密码，实现自动登录网站。
      单一环境里，用户变更密码都会反映到用户的个人文件夹中，而多架构中，比如用户在PC上变更密码，那么当用回到Mac上来时，钥匙链的密码和用户密码就不匹配了。oy钥匙链的密码和用户的登录密码不匹配的之后，钥匙链无法被正确的打开，其它程序也就无法访问里面的数据了。如果仅仅是不能访问忽略也就算里，有的程序，比如Safari，会频繁的询问用户钥匙链的密码，而用户可能忘了到底是哪个密码了，重复尝试无果后，会令用户很是烦恼。
      所以，教育用户养成在Mac电脑上变更密码的习惯，会成为管理员培训的一个重要话题。
 
打印机管理：


      即便是集成到AD，对打印机的管理依然是不可能的。一个用户登陆后，他可以使用的打印机被安装到本地，而所有其它用户都可以存取这个打印机，即便其它用户没有存取权限，这个问题存在于10.5之后。当然，在不复杂的环境里，可以通过管理方法绕过这个问题。
 
多种安全措施：


前面说了，MCX是目录服务中使用的管理手段，同时Mac还支持本地的ACLs和POSIX的安全措施，这样，在实施一个管理的时候，选择恰当的措施，而面对一个安全管理问题时，有可能是多方面的问题的组合，这就需要管理人员的经验和对系统知识的完备和灵活运用。
 
企业关键应用：


比如，如果你的系统依赖于Outlook，那么要慎重考虑为Mac用户提供的可用工具，因为Outlook For Mac并不提供完全的和Windows版Outlook的对应的功能。再比如Citrix的Java设置要求，可能和其它系统的要求产生冲突，等等。
 
ACLs的管理：


      Mac没有提供类似Windows里面的富GUI的管理方式，虽然可以通过Get Info简单管理，但是无法做到全面，要想细致全面管理，一定要使用CLI的命令行，当然这也是管理员的一个必修课程。
结束语：

      其实，基于我本人的喜好来说，相比较AD管理PC来说，我还是比较喜欢OD管理Mac的，Mac的管理比较直观理性快速和有效，程序安装简便等等诸多好处，既然时说瓶颈，那些好处这里不赘述了。


初稿：2010年12月28日

网络的开放性-网络支持系统共享，所以其最大的特点是对外开放，而用户众多，良莠不齐，从而导致误用滥用甚至恶意破坏的情况发生。
信息系统本身存在着脆弱性-黑客或故意破坏者，会利用系统不规范的安全配置，或者错误的配置打开入侵系统的缺口，用户的误操作或不恰当使用，会造成不安全的后果，甚至会导致系统崩溃，网络传输协议自身的弱点容易造成信息泄密。
管理者不重视系统的安全管理-即使有了很详细的安全解决方案，但如果管理混乱，技术粗糙，不及时更新，修补旧的漏洞就会使得安全解决方案形同虚设。事实表明绝大多数信息系统发生的不安全事件都可以从上述几点因素中找出原因。

作者：AWS企业市场战略总监 Stephen Orban 

 

“发展是一种以渐进式改善为载体的持续性行为”

——英德拉瓦蒂

 

虽然DevOps可以算是相对新鲜的概念，不过在我看来、其本质思路很早之前就已经出现。从这个角度看，目前很多企业已经广泛接纳这一概念并将其作为文化性产物看待，具体而言就是将大量原本孤立的团队融合起来，从而实现速度更快、频率更高且更为可靠的工作成果。

我个人非常幸运地早在DevOps文化进入主流视野之前就在自己的职业生涯当中对其有所了解。2001年，当时我在彭博公司担任开发人员，那时候彭博方面就已经凭借着其对于快速上市、压缩迭代开发周期以及由开发人员自行负责所交付系统的运营工作而享有盛誉。作为其中的一员，我这位开发新手很快就体会到了凌晨四点对系统进行故障排查的感受（那个时段伦敦证券交易所才刚刚开放）。我发现这些熬夜工作的经历反过来成为一种动力，敦促自己尽可能提升系统稳定性，从而避免这类夜不能寐的状况再次发生。

DevOps文化对于规模较小的初创企业而言往往比较直观，而且这类受众也会将结构调整作为相对简单的任务来看待。不过对于规模更大的组织机构，其中包含的大量技术欠债、整体架构惯性乃至尽可能避免风险的固有业务实践思路则让DevOps所宣扬的颠覆性看起来有些难以接受。

 

不过好消息是上述顾虑不一定真有必要，而且在未来几周内我会就DevOps在企业环境中的实现这一议题从多个特定角度及其发展战略着手加以探讨。我个人倾向于鼓励企业在DevOps的风潮当中向这一新型文化形式进行逐步转移——先从小型项目、迭代、学习以及改进起步。我建议大家考虑首先采取一些组织内部普遍能够接受的战略性实践尝试，并以此为切入点推广相关思维，从而最终让大多数团队能够在处理日常工作时对这类高自动化程度且以连续性运营为基础的文化趋势抱以信任的态度。

当初在担任道琼斯公司CIO时，我们针对一支小型团队建立起了自己的一套DevOps实践方案——该团队只有四到五名成员，但这已经足以推进实际项目了。不过我们的目标并非创建一个新的团队，而是要借此对企业的整体文化带来影响。通过实现及发明各类框架、最佳实践以及治理手段，并以自动化方式处理种种日常工作，DevOps最终成为我们驱动创新与加快产品开发的有力杠杆。我们从小规模项目入手，并将成果作为示例向其他同事证明我们能够利用同样的模式在更多项目当中取得成功。整个过程进展不快但却步伐坚定，其间我们不断推出新型功能并改进流程当中的产品上市时间。随着时间推移，原本常常因出现大量错误而令开发团队叫苦不迭的周二及周四版本发布日最终呈现出更具分散性的趋势——开发人员每周都会连续不断地推出数十项发布成果。

 

对于那些希望在DevOps领域作出尝试、但又对原有技术债务抱有疑虑的朋友，我建议大家将以下三项基本原则作为指导思想：

1.将面向客户的服务思路贯彻到企业的每个角落。

如今的企业应当将内部利益相关者作为客户来看待。这类客户可以是企业中的任何成员，包括市场推广人员、产品经理或者是开发人员。每位员工或者职能部门都需要对应的技术方案来完成自己的日常工作。而将这类需求作为优先事务处理的团队则能够满足客户的需求，从而避免其另外寻求解决方案（甚至是不合法的解决方案，例如影子IT），并最终带来理想的成果（例如速度更快、效果更好、成本更低）以及令人满意的客户反馈。相比之下，缺乏优质的服务则可能导致客户希望避开我们，而非与我们开展协作。

2. 尽可能推广自动化机制。

根据目前的主流理解，提升自动化水平的真正含义就是最大程度发挥云技术的固有优势，这意味着大家需要利用代码以可靠性为前提对系统进行重构。这一点在规模自动伸缩方面（也就是弹性）表现得尤为明显。自动化机制还能够帮助企业以更为积极的方式推进变更：如果我们犯了错误，则可以快速回滚至之前的状态，并重新开始系统构建。推广自动化机制的其它优势还包括更理想的执行效率、安全性以及可审计性。

3.谁构建，谁运行。

根据我的实际观察，这一点是最令传统IT部门感到不安的因素。在传统IT模式当中，应用程序或者服务的运维工作往往是由那些与资产创建毫不相干的人员来负责的。虽然这种处理方式并非毫无道理（例如选择成本更低的外包服务或者尽可能提高专业集中程度等），但我个人的观点是，这些优势目前已然不复存在了。云技术的出现如今已经接管了与IT运维工作相关的大部分高强度任务，而且其中多数运维工作也能够通过软件以自动化方式实现。开发人员显然对软件更为熟悉，这意味着如今已经没有理由将运维职责同任意给定任务进行硬性划分——而这也正是DevOps文化的根基所在。而且在自动化机制的帮助下，我们能够更加有条不紊地处理变更情况，并在问题影响到客户之前对其加以解决或者实现系统回滚。我建议大家建立起专门的DevOps团队，从而尽可能保证开发团队独立存在，而非将后者作为持续性运维/发布流程中的关键性环节。

 

对于有意愿在DevOps方面进行试水的朋友，我的观点是当下正是最理想的入手时机。先从小处出发，并通过增量化改进提升其它团队的满意度并赢得支持。文化层面的转变绝非一朝一夕之功，而我们也应当利用新型与传统等不同类型的方式实现此类改进。随着经验的持续积累，大家将一步步学习到足以指导下一步尝试的知识，同时运用日趋完善的自动化机制实现更为理想的工作成果。

 

在下一篇文章中，我们将共同解读建立一套以客户服务为核心的IT组织对于企业而言意味着什么。

您在DevOps方面拥有哪些心得及经验？请在评论当中分享您的真知灼见。

革命尚未成功，同志们多多加油！