[et_pb_section fb_built=”1″ admin_label=”Section” _builder_version=”4.22.0″ _module_preset=”default” custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” locked=”off” global_colors_info=”{}”][et_pb_row column_structure=”1_4,3_4″ _builder_version=”4.27.0″ _module_preset=”default” custom_padding=”50px||||false|false” custom_css_main_element=”z-index:0!important;” global_colors_info=”{}”][et_pb_column type=”1_4″ disabled_on=”on|on|off” _builder_version=”4.22.0″ _module_preset=”default” custom_padding=”||||false|false” sticky_position=”top” sticky_offset_top=”100px” sticky_limit_bottom=”section” motion_trigger_start=”top” global_colors_info=”{}”][et_pb_text admin_label=”indice” _builder_version=”4.27.6″ _module_preset=”default” custom_margin=”||0px||false|false” custom_padding=”||14px||false|false” link_option_url=”#1″ global_colors_info=”{}”]<\/p>\n
Sections<\/strong><\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=”3_4″ _builder_version=”4.27.0″ _module_preset=”default” custom_css_main_element=”z-index:0!important;” global_colors_info=”{}”][et_pb_text admin_label=”seccion” module_id=”1″ module_class=”ittopicscontent” _builder_version=”4.27.6″ _module_preset=”default” z_index=”0″ custom_margin=”0px||0px||true|false” custom_padding=”0px||0px||false|false” custom_css_main_element=”font-family:%22Pandora-Light%22;” locked=”off” global_colors_info=”{}”]Here we always talk about best practices, because it is the right thing to do and we were always good at school. But an enormous ocean separates IT theory from day-to-day practice… And it is full of monsters. For example, most MSPs<\/A> do not have a validation environment that reproduces their customers\u2019 reality<\/strong>. For once, this issue is not our negligence, seriously. So it is worth normalising it because, in reality, it is the very nature of the business<\/strong>. Chuck Palahniuk wrote Fight Club and said that the only way to find happiness was to risk being cut open. But Palahniuk did not work in IT, and the first key to automating directly in production is understanding those risks<\/strong>, or we really will end up cut open. After understanding the risks, we must understand the specific automations<\/strong> in the customer environment, because they are not all the same and our first exercise in caution is distinguishing the ones that bite from the ones that do not<\/strong>. Now, we are not identifying what is critical in order to give up on automating it. The key is to reserve the most careful treatment<\/strong> for it out of all the approaches we will see below.<\/p>\n Let\u2019s get to the heart of the matter. If we cannot test in a twin or similar environment, the strategy consists of turning production itself into our test bench, but in a controlled way<\/strong>, exposing each time only a small and recoverable portion<\/strong> of the total. If we look closely, none of these measures requires staging, only judgement based on a doomsday prepper mindset and a little patience<\/strong>. Automation, by definition, makes us lose direct control, because we take our hands off the wheel to focus on other things and pray that self-driving does not end up wrapped around a lamppost. The point is that the quality of subsequent traceability partly defines how much validation in a previous environment<\/strong> (which we do not have) we can skip. When we assemble everything above like the Avengers (progressive deployment, segmentation, planned rollback and observability), staging becomes less necessary and there will be signs that we are doing it right. The result is sustainable automation even when no real staging environment exists<\/strong>, which was exactly what seemed impossible at the beginning.<\/p>\n The most practical question is: what tools do we use to do all this without losing our minds? Habla con el equipo de ventas, pide presupuesto, o resuelve tus dudas sobre nuestras licencias<\/p>\n ” content_phone=”<\/p>\n Habla con el equipo de ventas, resuelve tus dudas sobre nuestras licencias o pide presupuesto<\/p>\n ” content_last_edited=”on|tablet” _builder_version=”4.22.0″ _module_preset=”default” header_2_font_size=”2em” text_orientation=”center” module_alignment=”left” custom_margin=”0px||20px||false|false” custom_padding=”0px||0px||true|false” global_colors_info=”{}”]<\/p>\n Habla con el equipo de ventas, pide presupuesto, [\/et_pb_text][et_pb_code _builder_version=”4.27.4″ _module_preset=”default” width=”200px” module_alignment=”center” custom_margin=”40px||0px||false|false” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”]<\/p>\n\n
\nThey have not set up a twin staging environment or a reliable replica, and they do not have that pristine laboratory where they can test automations before touching what matters. They have production and an intern made of caffeine with a finger on the push button. But production is where the paying customer lives, does not care about excuses and calls breathing fire<\/Strong>.
\nThe instinct in this case is usually either to give up on automation \u201cjust in case\u201d or to jump in headfirst and pray. The first of those doors condemns us to keep doing manually everything that erodes margin and consumes the team<\/a>. The second is piloting at warp speed while blind, so you go very fast… until you stop going.
\nHere we will open a third door, because not having a perfect validation environment does not mean giving up on automation, but it does mean designing it differently<\/strong>. In a more cautious, segmented and, above all, reversible way.
\nLet\u2019s see how.<\/p>\nWhy a real staging environment rarely exists in an MSP<\/h2>\n
\nAn MSP manages heterogeneous customers<\/strong>. Each one has its own operating system, its own version, its patch pending since the Cretaceous, its particular topology… Replicating that in a test environment would mean twenty different laboratories and this is where perfect theory does not fit into IT reality<\/strong>.
\nTo that we must add legacy infrastructures<\/strong>. Those systems that nobody dares to touch because nobody really knows how they work or which legendary character set them up, so they can rarely be cloned with guarantees.
\nBut above all stands the supreme ruler, money<\/strong>.
\nReplicating representative environments requires hardware, licences and hours that almost no MSP can allocate per customer<\/strong>.
\nTo rub salt into the wound, many parts of the managed infrastructure depend on external services<\/strong> (third-party APIs, integrations, the customer\u2019s own systems…) that are simply impossible to reproduce in an isolated environment<\/strong>.
\nDeep down, there is a matter of control, because an MSP does not own the customer\u2019s architecture<\/strong>. It manages it, yes, but it does not own it, which limits what it can build as a testing mirror.
\nIn that real life, so different from theory, reliable staging, when we talk about multi-customer environments, is the exception rather than the rule, so, more than a shameful secret to hide, we are talking about a design constraint we need to work with<\/strong>.
\nBut of course, that involves danger…<\/p>\nWhat risks appear when automating directly in production<\/h2>\n
\nThe first and most feared one is the rapid propagation of errors<\/strong>.
\nAutomation is, by definition, something we execute many times and very quickly. Wonderful when it works and a complete disaster when it does not, because a wrong script breaks two hundred servers before our jaw hits the floor when we see it.
\nSecond, there are changes that are difficult to diagnose<\/strong>.
\nWhen something is applied massively and simultaneously, it is also likely to start failing massively and simultaneously<\/strong>.
\nIn those cases, it is hard to know exactly what changed, in what order and where things started to go wrong.
\nAnd when what goes wrong is critical, it becomes a business challenge for the customer<\/strong> we promised their IT would run smoothly. We lose their trust, and trust is a porcelain vase: even if we painstakingly glue the pieces back together, it is never the same.
\nThe rest of the bill arrives later, because those risks make us fearful and inefficient<\/strong>.
\nSo we increase reactive supervision<\/strong>, because nobody can really trust it and we are watching everything all the time. Little by little, SLAs<\/A> also degrade<\/strong>, and rollback (that step back nobody designed because \u201ccome on, what could possibly fail?\u201d) becomes very expensive exactly when we need it most.<\/p>\nWhich automations are especially delicate without real validation<\/h2>\n
\nThe group of those we should treat as if we were defusing a bomb includes:<\/p>\n\n
How to reduce risk when we cannot test in a twin environment<\/h2>\n
\nLife in IT is a casino, and it is worth following the golden rule for surviving them: Never bet more than we can afford to lose<\/strong> in each move we make.
\nThat is why we do not act like James Bond and go \u201call on red\u201d, but instead apply progressive deployment, hoping for the best but preparing for the worst<\/strong>.
\nThis mindset is essential<\/strong> and, instead of applying that change suggested by the LLM to a thousand assets at once, we start with a small pilot group<\/strong>, observe while wiping away the cold sweat and, only if our nightmares do not come true, expand that deployment.
\nWe will never be 007 with that attitude, but a phased activation<\/strong> (where each phase confirms that the previous one did not go up in flames) will make the Mandalorian nod and say: \u201cThis is the way\u201d.
\nThat piloting is based on segmentation<\/strong>, and this is where an MSP paradoxically has an advantage (about time).
\nThat MSP works by customers and criticality levels (or at least, it should), which makes it possible to order deployments by starting with the least critical and most tolerant environments<\/strong>, leaving the services that cause the most heart attacks for last.
\nThis progressive deployment is a horse we ride carefully, adding a series of additional security safeguards<\/strong>, such as:<\/p>\n\n
\nThe bad part is that we often automate because of trends and FOMO, which makes us run around like headless chickens because \u201cwe do not want to fall behind and the competition has surely already applied it\u201d.
\nThe competition is going through the same thing as we are, and this connects with the typical mistakes when automating processes in an MSP<\/a>. Spoiler: almost all of them have the same father, wanting to go too fast.<\/p>\nWhat role the observability of automation itself plays<\/h2>\n
\nBut letting go of the wheel does not mean closing our eyes<\/strong>.
\nHence the need to monitor automation<\/strong> so that it does not gradually drift towards that lamppost.
\nSpock said: \u201cLogic is the beginning of wisdom, not the end\u201d. Automation is also only the beginning, and final wisdom is knowing what the thing we set running on its own is actually doing.
\nFor that, we need answers to very specific questions:<\/p>\n\n
\nIn the end, even with that previous laboratory, things will not turn out exactly the same, and the validation that counts is the one performed against reality<\/strong>.
\nBut without visibility, automating production without staging is Bond\u2019s \u201call on red\u201d, which only works in the movies.<\/p>\nWhat changes when an MSP automates production with proper criteria<\/h2>\n
\nThese are:<\/p>\n\n
How Pandora FMS helps automate in a controlled way without a full validation environment<\/h2>\n
\nPandora FMS<\/a> fits as the answer, but not because of magic or marketing, but because we designed and built it for multi-tenant battles<\/strong>.
\nThus, segmentation by groups and customers is native<\/strong>. Organising deployments by criticality or environment (those pilot groups we talked about earlier) goes from being a matter of hacks and workarounds to the natural way of working<\/strong> with our tool.
\nOn that basis, pre-change and post-change monitoring <\/strong>gives us the validations we saw could replace (at least partly) the previous laboratory. With Pandora FMS, we check the status before acting and confirm the result afterwards… automatically<\/strong>.
\nControlled automation<\/strong> makes it possible to execute corrective actions and responses without giving up verification or traceability, which is Pandora FMS\u2019s strong point. Since we are diving in headfirst without prior testing, at least we can closely observe every step we take to correct issues<\/strong>.
\nOur tool detects, acts, checks and records what it did and on what<\/strong>, which is what turns blind automation into controlled automation.
\nAnd all of this under centralised visibility<\/strong> from the Metaconsole<\/a>, that single pane of glass from which we observe the effects of change in real time and across all environments at once. The dream of being Marvel\u2019s Heimdall, able to hear even the smallest whisper in the nine realms.
\nAdded to this are consolidated alerts and events<\/strong>, with correlation and filtering so we do not drown in noise when something strange starts moving<\/a>.
\nAnd if security is comprehensive, Pandora SIEM<\/A> adds visibility of this type of event to the same picture<\/strong>. If an automated change opens a door it should not to malicious actors, it will not go unnoticed by Pandora.
\nIn the end, not having a perfect validation environment is not the end of automation in an MSP, because otherwise almost nobody would automate.
\nThe key is to stop thinking of automation as a switch we turn on all at once to see what happens. If we approach it as a gradual, observable and reversible process<\/strong> (deploying in phases, segmenting by criticality, validating before and after, and using rollbacks), we mitigate the risks of not having the perfect laboratory (which will probably never arrive).
\nWill we make mistakes? Of course, that is real life in IT, but the laboratory does not vaccinate us against that either and, by following the best practices we have seen, those inevitable failures will be small and drama-free.[\/et_pb_text][et_pb_button button_url=”@ET-DC@eyJkeW5hbWljIjp0cnVlLCJjb250ZW50IjoicG9zdF9saW5rX3VybF9wYWdlIiwic2V0dGluZ3MiOnsicG9zdF9pZCI6IjM2MjI3MCJ9fQ==@” button_text=”\u2190 Back to IT Topics” button_alignment=”left” _builder_version=”4.22.0″ _dynamic_attributes=”button_url” _module_preset=”default” custom_button=”on” button_text_size=”1em” button_text_color=”#0C312F” button_bg_color=”#FFFFFF” button_bg_color_gradient_direction=”90deg” button_bg_color_gradient_stops=”#82B92E 0%|#3CB92E 100%” button_bg_color_gradient_start=”#82B92E” button_bg_color_gradient_end=”#3CB92E” button_border_width=”1px” button_border_color=”#eaeaea” button_border_radius=”100px” button_use_icon=”off” z_index=”0″ custom_margin=”60px||0px||false|false” custom_padding=”10px|50px|10px|50px|true|true” custom_padding_tablet=”” custom_padding_phone=”10px|20px|10px|20px|true|true” custom_padding_last_edited=”on|phone” custom_css_main_element=”right:0!important;||font-family:%22Pandora-Bold%22!important;” global_module=”367749″ locked=”off” global_colors_info=”{}” button_bg_color__hover_enabled=”on|desktop” button_bg_color_gradient_start__hover=”#eaeaea” button_bg_color_gradient_end__hover=”#f4f4f4″ button_bg_color__hover=”#eaeaea” button_bg_enable_color__hover=”on” button_bg_use_color_gradient__hover=”on” button_bg_color_gradient_stops__hover=”#eaeaea 0%|#f4f4f4 100%”][\/et_pb_button][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ custom_padding_last_edited=”on|desktop” admin_label=”Final CTA” _builder_version=”4.27.0″ _module_preset=”default” background_color=”#161327″ use_background_color_gradient=”on” background_color_gradient_stops=”rgba(22,19,39,0.5) 17%|rgba(22,19,39,0.5) 100%” background_color_gradient_overlays_image=”on” background_image=”https:\/\/pandorafms.com\/wp-content\/uploads\/2023\/12\/banner-contacta-it-topics.webp” background_size=”custom” background_image_width=”121%” background_image_height=”192%” background_position=”top_left” z_index=”1″ max_width=”1080px” max_width_tablet=”98%” max_width_phone=”98%” max_width_last_edited=”on|tablet” module_alignment=”center” custom_margin=”80px||80px||true|false” custom_padding=”40px|20px|120px|20px|false|true” custom_padding_tablet=”40px|0px|120px|0px|false|true” custom_padding_phone=”40px|0px|120px|0px|false|true” scroll_scaling=”40|55|85|100|100%|120%|100%” motion_trigger_start=”top” background_last_edited=”on|phone” background_size_tablet=”cover” background_size_phone=”cover” background_position_phone=”top_center” border_radii=”off|20px|20px|20px|20px” border_color_all=”#ffffff” box_shadow_style=”preset1″ box_shadow_vertical=”0px” box_shadow_blur=”80px” box_shadow_color=”#506da0″ saved_tabs=”all” global_colors_info=”{}”][et_pb_row use_custom_gutter=”on” gutter_width=”2″ make_equal=”on” _builder_version=”4.22.0″ _module_preset=”default” max_width=”750px” module_alignment=”center” custom_margin=”0px||0px||true|false” custom_padding=”0px|0px|0px|0px|true|true” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.22.0″ _module_preset=”default” global_colors_info=”{}”][et_pb_text content_tablet=”<\/p>\n
o resuelve tus dudas sobre nuestras licencias<\/p>\n