{"id":31068,"date":"2019-10-31T21:39:16","date_gmt":"2019-10-31T18:39:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie\/"},"modified":"2019-10-31T21:39:16","modified_gmt":"2019-10-31T18:39:16","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","title":{"rendered":"How to Take Control of Your Network Infrastructure. Chapter One. Retention","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>This article is the first in a series titled 'How to Take Control of Your Network Infrastructure.' You can find the content of all articles in the series and links. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">here<\/a><\/noindex><\/i>.<\/p>\n<p>I can imagine that there are sufficient companies where a simple network not functioning for an hour or even a day isn\u2019t critical. Unfortunately or fortunately, I have not worked in such places. However, networks vary, requirements vary, and approaches vary, yet, in one way or another, the list below will be essentially a 'must-do' in many cases.<\/p>\n<p>So, here are the initial conditions. <\/p>\n<p>You are at a new job or have received a promotion, or you may be looking at your responsibilities in a new light. The company network is your area of responsibility. For you, this is largely a challenge and something new, which somewhat justifies the instructive tone of this article :). But, I hope this article can also be useful to any network engineer.<\/p>\n<p>Your first strategic goal is to learn to counteract entropy and maintain a level of service delivery. <\/p>\n<p>Many of the tasks described below can be addressed with various tools. I intentionally do not raise the topic of technical implementation, as what often matters is not so much how you solve a particular task but rather how you use it and whether you use it at all. For example, there is little use in having a professionally established monitoring system if you do not check it and respond to alerts.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Hardware<\/h2>\n<p>\nFirst, you need to understand where the biggest risks lie.<\/p>\n<p>Again, this can vary. I assume that in some cases it will be security issues, in others it will relate to service continuity, or perhaps something else. Why not?<\/p>\n<p>Let's assume for clarity that it is indeed service continuity (as it has been in all the companies I have worked for).<\/p>\n<p>Then you need to start with the equipment. Here is a list of topics to pay attention to:<\/p>\n<ul>\n<li>classification of equipment by criticality<\/li>\n<li>redundancy of critical equipment<\/li>\n<li>support and licenses<\/li>\n<\/ul>\n<p>\nYou need to consider possible failure scenarios, especially with the equipment at the top of your criticality classification. Often, the likelihood of dual failures is overlooked; otherwise, your solution and support may become unjustifiably expensive. However, for truly critical network elements whose failure could significantly impact the business, you need to think about this as well.<\/p>\n<blockquote><p><b>Example<\/b><\/p>\n<p>Let's assume we are talking about the core switch in the data center. <\/p>\n<p>Since we have agreed that service continuity is the most important criterion, it makes sense to ensure \"hot\" redundancy for this equipment. But that's not all. You also need to decide how much time, in the event of a primary switch failure, is acceptable for you to operate with just one remaining switch, as there is a risk that it may fail as well.<\/p>\n<p><b>Important! You should not resolve this matter alone. You must describe the risks, possible solutions, and costs to your management or company leadership. They should be the ones making decisions.<\/b><\/p>\n<p>So, if it has been decided that, given the low probability of a dual failure, operating for 4 hours on one switch is, in principle, acceptable, then you can simply obtain the appropriate support (under which the equipment will be replaced within 4 hours). <\/p>\n<p>But there is a risk that the replacement will not arrive. Unfortunately, we found ourselves in such a situation once. Instead of four hours, the equipment took a week to arrive!!!<\/p>\n<p>Therefore, this risk also needs to be discussed, and perhaps it would be wiser for you to purchase another switch (the third one) and keep it in spare inventory (\"cold\" redundancy) or use it for lab purposes.<\/p><\/blockquote>\n<p>\n<b>Important! Create a table of all your supports with expiration dates and add them to your calendar, so that at least a month in advance, you receive a notification that you should start worrying about renewing your support.<\/b><\/p>\n<p>You will not be forgiven if you forget to renew the support and your equipment fails the day after it expires.<\/p>\n<h2>Emergency Work<\/h2>\n<p>\nNo matter what happens in your network, ideally, you should maintain access to your network equipment. <\/p>\n<p><b>Important! You must have console access to all equipment, and this access should not depend on the functionality of the data transmission network.<\/b><\/p>\n<p>You should also anticipate potential negative scenarios in advance and document the necessary actions. The availability of this document is also critical, so it should not only be published on a common departmental resource but also saved locally on engineers' computers.<\/p>\n<p>It must contain <\/p>\n<ul>\n<li>the information necessary to open a support ticket with the vendor or integrator <\/li>\n<li>information on how to access any equipment (console, management)<\/li>\n<\/ul>\n<p>\nIt may also contain any other useful information, for example, descriptions of upgrade procedures for various equipment and useful diagnostic commands.<\/p>\n<h2>Partners<\/h2>\n<p>\nNow you need to assess the risks associated with partners. Typically, these are<\/p>\n<ul>\n<li>internet service providers and Internet exchange points (IX)<\/li>\n<li>telecommunication channel providers <\/li>\n<\/ul>\n<p>\nWhat questions should you ask yourself? Like with the equipment, consider various emergency scenarios. For example, for internet service providers, it could be something like:<\/p>\n<ul>\n<li>What if internet provider X stops providing you with service for some reason? <\/li>\n<li>Will the bandwidth of the other providers be sufficient?<\/li>\n<li>How good will the connectivity remain?<\/li>\n<li>How independent are your internet providers, and will a major outage of one cause problems with others?<\/li>\n<li>How many optical inputs does your data center have? <\/li>\n<li>What will happen if one of the inputs is completely destroyed?<\/li>\n<\/ul>\n<p>\nRegarding inputs, in my experience at two different companies, in two different instances, <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/en\/kompaniya\/data-centers\/\"   title=\"data centers\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"4668\">data centers<\/a> an excavator damaged manholes, and only by a stroke of luck was our fiber optics untouched. It's not that rare of an occurrence.<\/p>\n<p>And of course, you need to not only pose these questions but, once again, with the support of management, ensure that an acceptable solution is provided in any situation. <\/p>\n<h2>Backup<\/h2>\n<p>\nThe next priority may be the backup of equipment configurations. In any case, this is a very important point. I won't list the situations in which you might lose your configuration; it's better to regularly back it up and not think about it. Additionally, regular backups can be very useful for tracking changes.<\/p>\n<p><b>Important! Make backups daily. It's not such a large amount of data to skimp on this. In the morning, the on-duty engineer (or you) should receive a report from the system clearly stating whether the backup was successful or not, and in case of an unsuccessful backup, the issue should be resolved or a ticket should be created (see the network department processes). <\/b><\/p>\n<h2>Software Versions<\/h2>\n<p>\nThe question of whether or not to upgrade the software of the equipment is not so straightforward. On one hand, older versions have known bugs and vulnerabilities, but on the other hand, new software is not always an uncomplicated upgrade process, and additionally, new bugs and vulnerabilities may emerge.<\/p>\n<p>Here it is necessary to find the optimal option. A few obvious recommendations:<\/p>\n<ul>\n<li>only install stable versions<\/li>\n<li>it's still not advisable to run on very old versions of the software<\/li>\n<li>create a table with information about where which software is installed<\/li>\n<li>periodically read reports on vulnerabilities and bugs in software versions, and in case of critical problems, consider upgrading<\/li>\n<\/ul>\n<p>\nAt this stage, with console access to the equipment, information about support, and a description of the upgrade procedure, you are, in principle, ready for this step. The ideal scenario is having laboratory equipment where you can test the entire procedure, but unfortunately, that is not often the case.<\/p>\n<p>In the case of critical equipment, you can contact the vendor's support to assist you with the upgrade.<\/p>\n<h2>Ticketing System<\/h2>\n<p>\nNow you can take a look around. You need to establish processes for interaction with other departments and within your own department. <\/p>\n<p>This may not be mandatory (for instance, if your company is small), but I would highly recommend organizing work in such a way that all external and internal tasks go through a ticketing system.<\/p>\n<p>The ticketing system is essentially your interface for internal and external communications, and you should describe this interface with sufficient detail.<\/p>\n<p>Let's take an important and frequently encountered task of opening access as an example. I will describe an algorithm that worked well in one of the companies.<\/p>\n<blockquote><p><b>Example<\/b><\/p>\n<p>Let's start by noting that clients often formulate their access requests in a way that's unclear to network engineers, specifically in the language of applications, for example, 'grant me access to 1C.' <\/p>\n<p>Therefore, we have never accepted requests directly from such users. <br \/>\nAnd that was the first requirement.<\/p>\n<ul>\n<li>Access requests must come from technical departments (in our case, these were Unix, Windows, and helpdesk engineers).<\/li>\n<\/ul>\n<p>\nThe second requirement is that <\/p>\n<ul>\n<li>this access must be documented (by the technical department from which we received this request), and as part of the request, we receive a link to this documented access. <\/li>\n<\/ul>\n<p>\nThe form of this request must be understandable to us, meaning that <\/p>\n<ul>\n<li>the request should contain information about which subnet access should be granted to and from, as well as the protocol and (for TCP\/UDP) the ports.<\/li>\n<\/ul>\n<p>\nIt should also specify <\/p>\n<ul>\n<li>a description of why this access is being opened.<\/li>\n<li>Whether it is temporary or permanent (if temporary, until what date).<\/li>\n<\/ul>\n<p>\nAnd a very important point is the approvals.<\/p>\n<ul>\n<li>From the department head initiating the access (for example, accounting),<\/li>\n<li>from the head of the technical department from where this request came to the network department (for example, helpdesk).<\/li>\n<\/ul>\n<p>\nIn this case, the 'owner' of this access is considered to be the head of the department that initiated the access (accounting in our example), and they are responsible for keeping the page with documented accesses for this department up to date.\n<\/p><\/blockquote>\n<p><\/p>\n<h2>Logging<\/h2>\n<p>\nThis is where one can easily get bogged down. But if you want to implement a proactive approach, you need to learn how to manage this flow of data.<\/p>\n<blockquote><p>Here are a few practical recommendations:<\/p>\n<ul>\n<li>logs should be reviewed daily.<\/li>\n<li>In the case of scheduled reviews (and not emergency situations), you can limit yourself to severity levels 0, 1, 2 and add selected patterns from other levels if you consider it necessary.<\/li>\n<li>Write a script that parses the logs and ignores those logs whose patterns you have added to the ignore list.<\/li>\n<\/ul>\n<p>\nThis approach will allow you to gradually compile an ignore list of logs that do not interest you and retain only those that you truly consider important.<br \/>\nWe found this to work great for us.<\/p><\/blockquote>\n<p><\/p>\n<h2>Monitoring<\/h2>\n<p>\nIt's not uncommon for a company to lack a monitoring system. You might rely on logs, but hardware can simply 'die' without saying anything, or the UDP packet from the syslog protocol can be lost in transit. Overall, active monitoring is certainly important and necessary.<\/p>\n<blockquote><p>Two of the most requested examples from my practice:<\/p>\n<ul>\n<li>monitoring the load on critical communication channels (for instance, connections to providers). This allows one to proactively see potential service degradation issues due to traffic loss and, accordingly, avoid them.<\/li>\n<li>graphs built on NetFlow. They make it easy to identify traffic anomalies and are very helpful for detecting some simple yet significant types of hacking attacks.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\n<b>Important! Set up SMS notifications for the most critical events. This applies to both monitoring and logging. If you don\u2019t have a standby shift, SMS notifications should also be sent during non-working hours. <\/b><\/p>\n<p>Design the process in such a way that not all engineers are disturbed. We had a standby engineer for this purpose.<\/p>\n<h2>Change Control<\/h2>\n<p>\nIn my opinion, it is not necessary to monitor every change. Nonetheless, you should have the ability to easily find out who and why made specific changes to the network if needed. <\/p>\n<blockquote><p>A few tips:<\/p>\n<ul>\n<li>use a ticketing system to describe in detail what has been done within that ticket, for example, by copying the applied configuration into the ticket<\/li>\n<li>utilize comment capabilities on network equipment (for instance, commit comment on Juniper). You can note the ticket number<\/li>\n<li>use diffs of your configuration backups<\/li>\n<\/ul>\n<p>\nYou can formalize this as a process by reviewing all tickets daily for changes.<\/p><\/blockquote>\n<p><\/p>\n<h2>Processes<\/h2>\n<p>\nYou should formalize and describe processes within your team. If you've reached this point, your team should already have at least the following processes in place:<\/p>\n<p>Daily processes:<\/p>\n<ul>\n<li>working with tickets<\/li>\n<li>working with logs<\/li>\n<li>change control<\/li>\n<li>daily checklist<\/li>\n<\/ul>\n<p>\nAnnual processes:<\/p>\n<ul>\n<li>renewing warranties, licenses<\/li>\n<\/ul>\n<p>\nAsynchronous processes:<\/p>\n<ul>\n<li>responding to various emergency situations<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusion of Part One<\/h2>\n<p>\nHave you noticed that none of this is about network configuration, design, network protocols, routing, or security? It's something else altogether. But these may seem boring, yet they are crucial elements of a network department's work. <\/p>\n<p>So far, as you can see, you haven\u2019t improved anything in your network. If there were security vulnerabilities, they remain, and if there was poor design, it remains as well. You haven't applied your skills and knowledge as a network engineer, which likely took a significant amount of time, effort, and sometimes even money. But first, you need to build (or strengthen) the foundation before you can start constructing.<\/p>\n<p>The next parts will discuss how to find and troubleshoot issues, and then improve your infrastructure.<\/p>\n<p>Of course, it's not necessary to do everything sequentially. Time can be critical. Do things in parallel if resources allow.<\/p>\n<p>And a key point: Communicate, ask questions, and consult with your team. After all, they are the ones who will maintain and implement all this.<br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/433614\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb. \u0421\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0432\u0441\u0435\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0446\u0438\u043a\u043b\u0430 \u0438 \u0441\u0441\u044b\u043b\u043a\u0438 \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0437\u0434\u0435\u0441\u044c. \u0412\u043f\u043e\u043b\u043d\u0435 \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e, \u0447\u0442\u043e \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439, \u0433\u0434\u0435 \u043f\u0440\u043e\u0441\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u0432 \u043e\u0434\u0438\u043d \u0447\u0430\u0441 \u0438\u043b\u0438 \u0434\u0430\u0436\u0435 \u043e\u0434\u0438\u043d \u0434\u0435\u043d\u044c \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u044b\u043c. \u041c\u043d\u0435, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e \u0438\u043b\u0438 \u043a \u0441\u0447\u0430\u0441\u0442\u044c\u044e, \u043d\u0435 \u0434\u043e\u0432\u0435\u043b\u043e\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0432 \u0442\u0430\u043a\u0438\u0445 \u043c\u0435\u0441\u0442\u0430\u0445. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31068","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u043f\u0435\u0440\u0432\u0430\u044f. \u0423\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:39:16+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:39:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47How to Take Control of Your Network Infrastructure. Chapter One. Retention | ProHoster","description":"This article is the first in the series \"How to Take Control of Your Network Infrastructure.\"","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u043f\u0435\u0440\u0432\u0430\u044f. \u0423\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:39:16+00:00","article:modified_time":"2019-10-31T18:39:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31068","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 04:23:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:24:13","updated":"2026-01-21 04:23:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/31068","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=31068"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/31068\/revisions"}],"predecessor-version":[{"id":164546,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/31068\/revisions\/164546"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=31068"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=31068"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=31068"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}