@lu162 只能说在原有的基础上进步，往规范和效率的方向提升。但是在大企业中技术从来都不是问题，思想和认知才是。以下是建议：
1 、如果是记录数据中心的资产，不建议 GLPI ，个人感觉 glpi 更适合办公资产环境。数据中心你可以考虑 itop https://www.combodo.com/itop-193 。具体匹配情况要结合实际情况看
2 、先自己玩明白这套系统，用户、权限、数据导出、资产创建、修改、调整、报废等。还有资产的命名规则（这个其实很重要）、资产系统和实物的标签匹配（服务器上贴的资产标签，不能一个二维码了事，我们一般采取 SRV-192.168.1.10 这样的资产系统保持一致）
3 、在自己内部的小团队中推广应用，等小团队适应后找机会和上级或公司提，哪怕能得到口头上的同意，后续的推动都能容易些。等大家都觉得简单好用且高效后无需提醒会直接使用
4 、针对普通的用户（只是查数据、导出数据的）配置一个通用的只读用户即可。
5 、领导或高层的特定需要就自己加工后再给出来吧

@lu162 最主要的是思维观念的问题，想用技术思维解决管理的问题是很困难的。
1 、流程和资产管理这个用好了可以实现自动哈，能减少工作量。但是你能确保系统上的记录都是正确的？运维人员更换了交换机的物理端口接线，你确认资产管理系统能够自动记录到？服务器配置的 RAID 卡由 RAID 5 调整为 RAID10 你确认能识别？更换了故障硬盘，你能确保资产能自动产生？
2 、能确认所有的业务系统流程都打通了？领导看整体报告是否需要登录？领导给上级汇报也可以通过系统界面的方式展示？国资委审计要求的文档格式你能确认可以直接通过系统导出？合作伙伴和关联部门你也能保证都有对应的权限并且没有安全隐患？
3 、最重要的是：大领导对自动化这些有没有想法？有没有可能通过高层的动员统一大家用这套平台的想法？思想不统一是很难用好的

理想是美好的，现实是骨感的。当你能确保技术内部的人员都能通过系统完成日常工作，能够消除明显的错误（例如资产标签和实物匹配、设备功率和东环监控一致等），再来思考整体使用吧

研究过工单系统，完整的客服系统还需要考虑电话语音对接吧。开源的你可以参考
https://wiki.anas365.com/spaces/VirtualReal/pages/50823214/docker-zammad+%E5%B7%A5%E5%8D%95%E7%B3%BB%E7%BB%9F

seatable 应该挺适合 https://wiki.waringid.me/spaces/VirtualReal/pages/46039359/Docker-%E5%9C%A8%E7%BA%BF%E8%A1%A8%E6%A0%BC+Teable%EF%BC%88%E5%8F%82%E8%80%83%EF%BC%89

只有我觉得 Seatable 才是最好用的吗？

@5261 是直接指定 Nginx 的内网地址

按照中国会计准则的新规定，数据作为企业资产可以计入“无形资产”，我认为这并没有任何创新，因为在中国的企业会计准则中，很多年前就已经把“软件”定义成无形资产，可以进入财务报表。

“数据”的形态是什么呢，不就是 API 或者 XLS 、TXT 、CSV 文件吗？或者就是 010101 的二进制机器代码，这些技术对象本身就是“软件”的一种，所以数字化的数据资产其性质根本上就是软件，再去定义“数据是无形资产”，纯属画蛇添足。

软件资产的估值方式一般采用购置（包括重置）价格或者开发成本，数据也可以采用类似方式，然而数据生成是自动的、甚至是熵增，所以实际估值非常困难——我经历过几个数据资产估值项目，目前根本没有符合准则的公认方法。

seafile?

iredmail

感受下气氛

showdoc 吧

云环境中 ECS 之类的计算资源很便宜，这个主要是用来引流和对标的（让人觉得云上资源很便宜），但是以下这几个大头的应用就被忽略了。
1 、RDS 数据库服务（特别是启用了高可用多节点的群集），可以参照自有 IDC 的数据库配置让顾问报下这个费用（ CPU 、内存、存储），这里的存储是按存储容量收取费用的
2 、Redis 或 ES 群集费用
3 、网络带宽费用
4 、安全费用（ WAF 之类）

也可以换一种思路：用 ECS 主机自己搭建 MSSQL 的高可用环境

1 、将现在的 RDS 服务改为 3 台 ECS 服务器
2 、在 ECS 服务器上自主安装配置 MSSQL 服务
3 、配置并启用 MSSQL 的 always on ，如果可以分离数据库的读操作
4 、是否需要启用 NLB 结合使用效果再调整

一是看这个出错的页面报什么错误 大部份的是数据库没有正确配置导致

另外去安装的后台界面看安装的日志文件 日志文件里会有详细的出错信息

@lengrongec ZFS 文件系统肯定是没问题的，存储最大的要求是稳定（硬件和相关配件的稳定也是基础要求）。如果使用普通的机架式服务器可以考虑 truenas 系统（需要稳定的考虑 freebsd 的版本，但需要注意硬件和系统的匹配）

飞书里的会议功能

@lengrongec 当前分布式存储都是基于 IP 网络，FC-SAN 和匹配的 HBA 卡和 FC 交换机只能配置独立存储（传统的磁盘柜模式）。也就是只能选 ZFS 的方案

想法是很美好的，但是零售涉及很多环节，各个环节都需要均衡不能出现短板，否则很容易栽跟头。要从这些环节上思考自己的优势和特点。和软件行业类似，店铺经营也需要有自己的特色能力才能匹配对应的消费群体。
1 、店铺位置。包括但不限于店铺的租金（要不要转让费），租约要求（能签多少年）、店铺覆盖的人群（流动人员、小区、单位、城中村等），例如小区对应的群体（消费能力，可以看小区的停车费用、所停的车辆、车辆的价位、小区的主要人群：老年、家庭、中年、实际入住率：看每晚亮灯的情况等）。综合这些因素评估成本和服务的人群

2 、商品。生鲜商品的损耗大概是 40%，如果没有把握，需要先少量进货试点。商品的品质也决定店铺经营的口碑，如果没有稳定的进货渠道（ 1 、畅销的商品不能经常缺货 2 、价格需要保持稳定 3 、商品的口味保持一致）很容易搞砸口碑。
同时需要结合店铺覆盖的人群选择相关的商品：考虑消费能力、年龄层次、消费需求、店铺自身特色等

3 、经营。日常经营涉及的方面更多。店铺的卫生、环境、灯光、温度、商品摆放和促销策略都需要按不同的条件调整并保持

4 、优势部分。能玩转系统和会员。会员积累和口碑效应是面对竞争的优势，只有保持这 2 个优势才能确保有盈利的可能（要考虑品牌连锁竞争开店）。好的口碑需要时间积累（商品品质、价格、服务）。

综合分析，要做好长期考虑（例如预计亏半年）积累经验、客户资源和口碑，通过长期的品质和口碑引流，最终实现类似会员的区域性经营（这也决定了目标客群不太可能是老年人和对价格敏感的人群）

@euph
1 、收集和消费数据。只有线上下单商家获取到的客户信息才是最全面的（例如微信 openid 、手机号、手机型号、手机配置、手机系统版本、IEMI 号码、商品信息、下单时间、历史购物记录等），从这些数据里可以提取消费者的标签：例如高端消费人群、进口食品爱好者、足球季、夜宵、90 后、烟民等，即使商品上盈利能力有限，这些消费者的数据标签（包括个体和群体的）也能产生价值（内部营销推广或者卖给外部的商业企业）

2 、降低运营成本。这种类型本质就是个仓库，只需要每天定时补货即可（补货时同时整理商品陈列摆放），同时店里没有人员服务，发生客诉也只能通过线上的方式维权，这样的方式其实就是线上商城小型化同时搬到了线下，连补货的操作都可以是通过系统管理，实际经营者都不需要出面甚至只需要出钱开店即可（需要考验后端系统管理匹配能力和门店实际损耗）