{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps and Chaos: Software Delivery in a Decentralized World","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

The founder and director of \"Otomato Software\", one of the initiators and instructors of the first DevOps certification in Israel, Anton Weiss, spoke last year DevOpsDays Moscow<\/a><\/noindex> about chaos theory and the main principles of chaos engineering, as well as explaining how the ideal DevOps organization of the future is structured.<\/p>\n

We have prepared a text version of the report. <\/p>\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\nGood morning! <\/p>\n

DevOpsDays in Moscow for the second consecutive year, I am on this stage for the second time, many of you are in this hall for the second time. What does this mean? It means that the DevOps movement in Russia is growing, multiplying, and most importantly, it means that it's time to talk about what DevOps is in 2018. <\/p>\n

Raise your hands if you think that in 2018, DevOps is already a profession? There are some. Are there DevOps engineers in the hall whose job description includes 'DevOps engineer'? Are there any DevOps managers in the room? None. DevOps architects? Also none. Not many. Really, does no one have 'DevOps engineer' written in their job description?<\/p>\n

So, most of you think this is an anti-pattern? That such a profession shouldn't exist? We can think whatever we want, and while we think, the industry is confidently moving forward to the sounds of the DevOps trumpet.<\/p>\n

Who has heard about the new topic called DevDevOps? It's a new methodology that enables effective collaboration between developers and DevOps. Although, it's not that new. Judging by Twitter, discussions started about this four years ago. And interest in it continues to grow, which means there is a problem. The problem needs to be addressed.<\/p>\n

\"DevOps
\n
\nWe are creative people; we don't calm down easily. We say: DevOps is not an all-encompassing term; we need various interesting elements. So we go to our secret labs and start creating curious mutations: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.<\/p>\n

\"DevOps
\n
\nThe logic is sound, right? Our delivery system is non-functional, our systems are unstable, and users are dissatisfied; we are not able to release software on time, and we are not sticking to the budget. How are we going to solve all this? We will come up with a new word! It will end with 'Ops', and the problem will be solved.<\/p>\n

I call this approach 'Ops, and the problem is solved'.<\/p>\n

Everything fades into the background when we remind ourselves why we came up with all this. We developed all this DevOps to make software delivery and our own work in this process as seamless, painless, efficient, and, most importantly, enjoyable as possible. <\/p>\n

DevOps emerged from pain. We got tired of suffering. To make it all happen, we rely on evergreen practices: effective collaboration, flow practices, and most importantly, systems thinking, because without it, no DevOps will work.<\/p>\n

What is a system?<\/b><\/h3>\n

\nAnd since we\u2019re talking about systems thinking, let\u2019s remind ourselves what a system is.<\/p>\n

\"DevOps
\n
\nIf you're a revolutionary hacker, then a system is unequivocally evil. It's a cloud that hovers over you and makes you do things you don't want to do. <\/p>\n

\"DevOps
\n
\nFrom the perspective of systems thinking, a system is a whole made up of parts. In this sense, each of us is a system. The organizations we work for are systems. And what we are building together is called a system.<\/p>\n

All of this is part of one large sociotechnical system. Only if we understand how this sociotechnical system works together can we truly optimize anything. <\/p>\n

From a systems thinking perspective, a system has different interesting properties. First, it consists of parts, which means that its behavior depends on the behavior of those parts. At the same time, all its parts are interdependent. This means that the more parts a system has, the harder it is to understand or predict its behavior. <\/p>\n

From a behavioral perspective, there\u2019s another interesting fact. A system can do something that none of its individual parts can do. <\/p>\n

As Dr. Russell Ackoff (one of the founders of systems thinking) said, this can be easily demonstrated through a thought experiment. For example, who in the room knows how to write code? Many hands go up, and that\u2019s normal because it\u2019s one of the main requirements of our profession. You can write, but can your hands, separately from you, write code? There are people who would say, 'It\u2019s not my hands that write code; it\u2019s my brain that writes code.' But can your brain write code separately from you? Most likely not. <\/p>\n

The brain is an amazing machine; we don't even understand 10% of how it works. However, it cannot function separately from the system that is our body. This is easy to prove: open your skull, take out your brain, place it in front of a computer, and let it try to write something simple, like 'Hello, world' in Python.<\/p>\n

If a system can do something that none of its parts can do individually, it means that its behavior is not defined by the behavior of its parts. So what does define it? It is defined by the interactions between these parts. Therefore, the more parts there are, the more complex the interactions, making it more difficult to understand and predict the behavior of the system. This complexity makes such a system chaotic, because even the slightest, invisible change to any part of the system can lead to completely unpredictable results. <\/p>\n

This sensitivity to initial conditions was first discovered and studied by American meteorologist Ed Lorenz. It later became known as the 'butterfly effect' and led to the development of a movement in scientific thought known as 'chaos theory.' This theory has become one of the major paradigm shifts in 20th-century science.<\/p>\n

Chaos Theory<\/b><\/h3>\n

\nPeople who study chaos call themselves chaosologists.<\/p>\n

\"DevOps
\n
\nThe real reason for this presentation is that while working with complex distributed systems and large international organizations, I eventually realized that this is what I feel I am. I am a chaosologist. It's a rather clever way of saying: 'I don't understand what is happening here and I don't know what to do about it.' <\/p>\n

I think many of you often feel this way too, so you are also chaosologists. I invite you to join the guild of chaosologists. The systems that we, dear chaosologist colleagues, will study are called 'complex adaptive systems.' <\/p>\n

What is adaptability? Adaptability means that the individual and collective behavior of the components in such an adaptive system changes and self-organizes in response to events or chains of micro-events within the system. In other words, the system adapts to changes through self-organization. This ability to self-organize is based on voluntary, fully decentralized cooperation among free autonomous agents.<\/p>\n

Another interesting property of such systems is that they are freely scalable. This is certainly something that should interest us as chaos engineers. So, if we say that the behavior of a complex system is determined by the interaction of its parts, what should we focus on? The interactions. <\/p>\n

There are two more interesting conclusions.
\n \"DevOps
\n
\nFirst, we understand that a complex system cannot be simplified by simplifying its parts. Second, the only way to simplify a complex system is through simplifying the interactions between its components. <\/p>\n

How do we interact? All of us are parts of a large information system known as human society. We interact through a common language, if we have one, if we find it.<\/p>\n

\"DevOps
\n
\nBut language itself is a complex adaptive system. Accordingly, in order to interact more effectively and simply, we need to create certain protocols. That is, some sequence of symbols and actions that will make information exchange between us simpler, more predictable, and more understandable.<\/p>\n

I want to say that trends towards complexity, adaptability, decentralization, and chaos can be seen everywhere. In the systems we build and in the systems we are a part of.<\/p>\n

And to substantiate this, let\u2019s look at how the systems we create are changing.<\/p>\n

\"DevOps
\n
\nI know you've been waiting for this word. We are at a DevOps conference, and this word will be heard somewhere around a hundred thousand times today, and then it will haunt us in our dreams.<\/p>\n

Microservices are the first software architecture that emerged as a response to DevOps practices aimed at making our systems more flexible and scalable, ensuring continuous delivery. How does it achieve this? By reducing the volume of services, narrowing the scope of problems these services handle, and shortening delivery times. In other words, we simplify parts of the system by increasing their quantity, which inevitably increases the complexity of interactions between these parts, leading to new challenges we need to address.<\/p>\n

\"DevOps
\n
\nMicroservices are not the end; they are, in fact, a relic of the past, as Serverless emerges. All servers have burnt out; there are no servers, no operating systems, just pure executable code. Configurations are separate, states are separate, and everything is managed by events. Beauty, clarity, tranquility\u2014there are no events, nothing happens, everything is in order. <\/p>\n

Where lies the complexity? Obviously, it is in the interactions. How much can one function do on its own? How does it interact with other functions? Message queues, databases, load balancers. How do you recreate an event when a failure occurs? A myriad of questions and few answers.<\/p>\n

Microservices and Serverless are what we, the computer hipsters, call Cloud Native. It\u2019s all about the cloud. Yet, the cloud is inherently limited in scalability. We tend to think of it as a distributed system. In reality, where do the servers of cloud providers reside? In data centers. So, we have a certain centralized, very limited, distributed model.<\/p>\n

Today, we understand that the Internet of Things is no longer just a buzzword; even modest predictions suggest that in the next five to ten years, billions of devices will be connected to the internet. A vast amount of both useful and useless data will flow into and out of the cloud. <\/p>\n

The cloud won\u2019t withstand this, which is why we increasingly talk about what is called 'edge computing.' Or, I particularly like the wonderful definition of 'fog computing.' It is wrapped in the mystique of romanticism and mystery.<\/p>\n

\"DevOps
\n
\nFog computing refers to centralized clusters of water, vapor, ice, and stones. Fog, on the other hand, comprises tiny water droplets dispersed around us in the atmosphere. <\/p>\n

In the foggy paradigm, most of the work is done by these droplets autonomously or in collaboration with other droplets. They approach the cloud only when absolutely necessary. <\/p>\n

This indicates decentralization and autonomy, and of course, many of you already understand where this is heading since it's impossible to talk about decentralization without mentioning blockchain. <\/p>\n

\"DevOps
\n
\nThere are those who believe, primarily those who have invested in cryptocurrency. There are those who are skeptical but still hold some belief, like me, for example. And then there are those who do not believe at all. Perspectives can vary here. There is a technology, a new and puzzling venture, and there are challenges. Like any new technology, it raises more questions than it provides answers. <\/p>\n

The hype surrounding blockchain is understandable. Even setting aside the gold rush, the technology itself holds remarkable promises for a brighter future: more freedom, greater autonomy, and distributed global trust. What\u2019s not to want? <\/p>\n

Consequently, more and more engineers around the world are beginning to develop decentralized applications. This is a force that cannot be ignored merely by stating, \"Ah, blockchain is just a poorly implemented distributed database.\" Or as skeptics love to say, \"There are no real applications for blockchain.\" If you think about it, 150 years ago they said the same about electricity. And they were even partly right, because what electricity enables today was utterly inconceivable in the 19th century.<\/p>\n

By the way, does anyone know what the logo on the screen is? That\u2019s Hyperledger. It\u2019s a project being developed under the auspices of The Linux Foundation, consisting of a set of blockchain technologies. This is indeed the strength of our open-source community.<\/p>\n

Chaos engineering<\/b><\/h3>\n

\n\"DevOps
\n
\nSo, the system we are developing is becoming increasingly complex, chaotic, and adaptive. Netflix are pioneers of microservices. They were among the first to recognize this, creating a set of tools known as Simian Army, the most well-known of which is Chaos Monkey<\/a><\/noindex>. It established what has become recognized as \"Principles of Chaos Engineering\"<\/a><\/noindex>.<\/p>\n

By the way, during the process of working on the report, we even translated this text into Russian, so feel free to check it out at the link<\/a><\/noindex>, read, comment, criticize.<\/p>\n

In short, the principles of chaos engineering state the following: complex distributed systems are inherently unpredictable and contain errors by nature. Errors are inevitable, which means we must accept these errors and approach these systems in a completely different way. <\/p>\n

We should intentionally introduce these errors into our production systems to test their adaptability, self-organization, and resilience. <\/p>\n

And this changes everything. Not only how we deploy systems into production, but also how we develop and test them. There is no stabilization process, no code freeze; instead, there is a continuous process of destabilization. We aim to break the system and observe that it continues to survive.<\/p>\n

Distributed System Integration Protocols<\/b><\/h3>\n

\n\"DevOps
\n
\nConsequently, this requires our systems to change as well. To become more resilient, they need new interaction protocols among their components. So these components can negotiate and achieve some level of self-organization. This gives rise to various new tools and protocols, which I refer to as \"protocols for interacting distributed systems.\"<\/p>\n

\"DevOps
\n
\nWhat am I talking about? Firstly, the Opentracing<\/a><\/noindex>project. An attempt to create a common protocol for distributed tracing, which is an indispensable tool for debugging complex distributed systems.<\/p>\n

\"DevOps
\n
\nNext is and that this action is permitted.<\/a><\/noindex>We say that we cannot predict what will happen to the system, meaning we need to enhance its observability. Opentracing belongs to a family of tools that provide observability for our systems. But we need observability to determine whether the system behaves as we expect it to or not. How can we identify the expected behavior? By establishing some policy, a set of rules within it. The Open Policy Agent project focuses on defining this set of rules across a wide range: from access control to resource allocation.<\/p>\n

\"DevOps
\n
\nAs we mentioned, our systems are increasingly event-driven. Serverless is a great example of event-driven systems. For us to transfer events between systems and track them, we need a common language, a common protocol for how we talk about events, how we pass them to each other. This is handled by a project called Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nThe continuous stream of changes that washes over our systems, constantly destabilizing them, is a continuous stream of software artifacts. To maintain this constant flow of changes, we need a common protocol that allows us to communicate what a software artifact is, how it is validated, and what verification it has undergone. This is addressed by a project called Grafeas<\/a><\/noindex>. That is, a common protocol for software artifact metadata.<\/p>\n

\"DevOps
\n
\nAnd finally, if we want our systems to be fully autonomous, adaptive, and self-organizing, we must grant them the right to self-identify. The project called spiffe<\/a><\/noindex> is exactly what this is about. It is also a project under the auspices of the Cloud Native Computing Foundation.<\/p>\n

All of these projects are young and need our love, our validation. They are all open source, our testing, our implementation. They show us the direction technology is moving. <\/p>\n

But DevOps has never been primarily about technology; it has always been about collaboration among people. Accordingly, if we want the systems we develop to change, we must change ourselves. In fact, we are already changing; we have little choice. <\/p>\n

\"DevOps
\n
\nThere is a wonderful book<\/a><\/noindex> British writer, Rachel Botsman, who writes about the evolution of trust throughout human history. She states that initially, in primitive societies, trust was local; we only trusted those we knew personally. <\/p>\n

Then came a very long period \u2014 a dark time when trust was centralized, when we began to trust people we did not know based on our belonging to a common social or governmental institution.<\/p>\n

And here is what we see in our modern world: trust is becoming increasingly distributed and decentralized, based on the freedom of information flow and the availability of information. <\/p>\n

If you think about it, it is this very availability that makes this trust possible, and we are the ones who enable it. This means that both how we collaborate and how we do it must change, because centralized hierarchical IT organizations of the old kind are becoming ineffective. They are starting to fade away. <\/p>\n

Fundamentals of a DevOps Organization<\/b><\/h3>\n

\nThe ideal DevOps organization of the future is a decentralized, adaptive system consisting of autonomous teams, each made up of self-sufficient individuals. These teams are spread across the globe, collaborating effectively with each other through asynchronous communication and highly transparent information exchange protocols. Quite beautiful, isn\u2019t it? A very beautiful future.<\/p>\n

Of course, all this is impossible without cultural changes. We must have transformational leadership, personal responsibility, and intrinsic motivation.<\/p>\n

\"DevOps
\n
\nThis is the foundation of DevOps organizations: transparency of information, asynchronous communications, transformational leadership, decentralization. <\/p>\n

Burnout<\/b><\/h3>\n

\nThe systems of which we are a part and those we build are becoming increasingly chaotic, and we, as people, struggle to cope with this reality, grappling with the illusion of control. We attempt to keep controlling them, and this often leads to burnout. I speak from personal experience; I have also burned out and become a casualty of unforeseen production failures.<\/p>\n

\"DevOps
\n
\nBurnout occurs when we try to control what is essentially uncontrollable. When we burn out, everything loses meaning because we lose the desire to create something new, we go into a defensive position, and start protecting what exists. <\/p>\n

The engineering profession, as I often like to remind myself, is primarily a creative profession. If we lose the desire to create something, we turn to ashes, we become dust. People burn out, entire organizations burn out.<\/p>\n

In my opinion, only by embracing the constructive power of chaos, only by building collaboration on its principles, can we avoid losing the good that exists in our profession. <\/p>\n

That's what I wish for you: to love your work, to love what we do. This world feeds on information, and we have the honor of nourishing it. So let's study chaos; let's be chaosologists, let's bring value, create something new. Well, problems, as we have already discovered, are inevitable, and when they arise, we will simply say 'Ops!', and the issue will be resolved. <\/p>\n

What besides Chaos Monkey?<\/b><\/p>\n

In fact, all these tools are quite new. Netflix themselves developed their tools. Build tools for yourself. Read the principles of chaos engineering and adhere to these principles, rather than trying to find other tools that someone else has already built. <\/p>\n

Try to understand how your systems fail and start breaking them to see how they withstand impacts. That comes first. As for tools, those can be found. There are many projects. <\/p>\n

I didn't quite understand the point when you mentioned that a system cannot be simplified by simplifying its components, and then immediately transitioned to microservices, which precisely simplify the system by simplifying the components while complicating the interactions. These are essentially two parts, contradictory to each other. <\/b><\/p>\n

Absolutely, microservices are a very controversial topic in general. In fact, simplifying parts increases flexibility. What do microservices give us? They provide flexibility and speed, but they certainly do not provide simplicity. They increase complexity.<\/p>\n

So in the philosophy of DevOps, microservices are not necessarily a blessing?<\/b><\/p>\n

Every blessing has a downside. There is a blessing: it increases flexibility, allows us to make changes faster, but it also raises complexity and, consequently, the fragility of the entire system. <\/p>\n

So where should the emphasis be placed: on simplifying interactions or on simplifying parts?<\/b> <\/p>\n

The focus is undoubtedly on simplifying interactions, because if we look at it from the perspective of how we work together, we must primarily pay attention to simplifying interactions rather than simplifying the work of each of us individually. Simplifying work turns us into robots. This works well at McDonald's, where you are told: place the burger here, pour the sauce on it here. This does not apply at all to our creative work.<\/p>\n

Is it true that everything you described exists in a world without competition, where chaos is so kind, and there are no contradictions within that chaos, and no one wants to eat or kill anyone? How should competition and DevOps coexist?<\/b><\/p>\n

Well, it depends on what kind of competition we are talking about. Competition in the workplace or competition between companies? <\/p>\n

About the competition of services that exist, because services are not just a few companies. We are creating a new type of information environment, and no environment can exist without competition. There is competition everywhere.<\/b><\/p>\n

Take Netflix as a role model. Why did they come up with this? Because they needed to be competitive. This flexibility and speed of movement is precisely that competitive requirement; it brings chaos into our systems. So chaos is not something we consciously create because we want it; it happens because the world demands it. We just have to adapt. And chaos is precisely the result of competition.<\/p>\n

Does that mean chaos is the absence of goals somehow? Or, rather, the goals that we do not want to see? We are in our little house and do not understand the goals of others. Competition, in fact, depends on the fact that we have clear goals, and we know where we will be at every moment in time. In my opinion, this is the essence of DevOps.<\/b><\/p>\n

Another perspective on the issue. I believe that we all share one goal: to survive and do it with
\nthe greatest pleasure. And the competitive goal of any organization is the same. Survival often occurs in competitive struggle; there's nothing to be done about that.<\/p>\n

This year's conference DevOpsDays Moscow<\/a><\/noindex> will take place on December 7 at 'Technopolis'. We are accepting submissions for presentations until November 11. Contact<\/a><\/noindex> us if you want to speak.<\/p>\n

Registration for participants is open, the ticket costs 7000 rubles. Join us! \n<\/p><\/blockquote>\n

Source: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47DevOps and Chaos: Software Delivery in a Decentralized World | ProHoster","description":"The founder and director of \"Otomato Software\", one of the initiators and instructors of the first DevOps certification in Israel, Anton Weiss, spoke last year","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","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\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","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-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","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-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20","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\/39219","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=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}