An UPDATE without a WHERE, or something close to it
There is certainly a tension in modern devops tools, between the desire to do things easily across large sets of machines (and especially across large sets of <i>diverse</i> machines) easily, and the fact that you lose all the <i>advantages</i> of inertia and difficulty in making stupid changes the better you get at that. As you scale up this tension gets worse and worse. You don&#x27;t really want to create a tool that allows you to trash &quot;every router you have&quot; in one fell swoop, or to trash &quot;every server in every data center&quot;, and yet at the same time, you <i>need</i> the ability to manipulate &quot;every server&quot; at the same time with the same tool because who can afford to log in and manually change 20,000 machines? It&#x27;s really difficult to have &quot;the power to administer&quot; 20,000 machines without having &quot;the power to destroy&quot; them all.<p>You can&#x27;t even easily ask &quot;are you sure?&quot; because if you&#x27;re asking that for every little thing it ceases to be a useful guard. You need tools that detect if you&#x27;re doing something stupid and dangerous and only ask then, but in the limit, that&#x27;s strong-AI hard for ops people. That is, there are some obvious ones you can try to catch... &quot;did you really mean to unassign all IP addresses?&quot;, but in general there&#x27;s always something that will go wrong more cleverly than your detection code.<p>Hooking machines up to orchestration code is something I have to do. I operate at scales that Facebook would laugh at, but they&#x27;re <i>still</i> well beyond what is practical to manually manage. In my opinion that scale taps out somewhere in the large single digits per ops person, which is nothing nowadays. But it always makes me nervous to do so, too, because I can see I&#x27;m putting all my eggs in one basket in the process, and the traditional &quot;watch that basket really hard!&quot; answer for when you&#x27;re stuck in that situation is visibly not adequate.<p>I don&#x27;t have a solution to propose. The tension seems fundamental to me. All I can suggest is that everyone sitting in front of any devops tool always be keeping the possibilities in mind, despite your brain&#x27;s desires to say &quot;hey, the last 1000 deploys went fine, I can stop being so vigilant about this one&quot;, and that any guard rails that can be added should be, even though they can never be 100% effective.