<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Device Management on Mi&amp;Bee Blog</title><link>https://blog.mickeyzzc.tech/en/tags/device-management/</link><description>Recent content in Device Management on Mi&amp;Bee Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>蓝宝石的傻话</managingEditor><lastBuildDate>Sun, 05 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.mickeyzzc.tech/en/tags/device-management/rss.xml" rel="self" type="application/rss+xml"/><item><title>MiBeeSteward: Why I Built Another Device Management Tool in Go</title><link>https://blog.mickeyzzc.tech/en/posts/mibee-oss/mibeesteward-introduction/</link><pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate><guid>https://blog.mickeyzzc.tech/en/posts/mibee-oss/mibeesteward-introduction/</guid><description>&lt;p&gt;As a studio operator, the biggest pain point is never a specific problem — it&amp;rsquo;s the &amp;ldquo;not knowing&amp;rdquo; when devices multiply.&lt;/p&gt;
&lt;p&gt;Not knowing which devices are alive, what services are running on them, whether a new machine has appeared on the network, whether a certain port is still open. This accumulated &amp;ldquo;not knowing&amp;rdquo; eventually becomes an outage.&lt;/p&gt;
&lt;p&gt;My previous approach was a patchwork: Zabbix for monitoring, Nmap for scanning, Excel for asset tracking, Prometheus for metrics. Each tool is fine on its own, but together they&amp;rsquo;re a disaster — data silos, duplicate configuration, version drift, complex deployment.&lt;/p&gt;</description></item></channel></rss>