Хабрахабр

Как измерить успех. Стратегии мониторинга и их связь с бизнес-проблемами

Для Dev и Ops определение успеха отличается. Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас. Для эксплуатации — мониторинг. Для Dev успешный проект полностью проходит тестирование. Leon Fayer на РИТ++ отстаивал точку зрения, что DevOps платят не за то, чтобы все метрики в мониторинге были в зеленой зоне. Тестирование и мониторинг нужны, но тесты никогда не дают 100% покрытия проблемы, а ответа 200 от HTTP недостаточно, чтобы быть уверенным в том, что система хорошо работает. Если недовольны — бизнес теряет деньги, и никого не волнует, что все зеленое. Платят за то, чтобы пользователи были довольны.

Разберем, зачем понимать бизнес, как следить за успехом с точки зрения бизнеса, и зачем это нужно простым разработчикам. Под катом много примеров из практики, которые доказывают эту точку зрения.

Начал заниматься программированием очень много лет назад, и за это время работал программистом, менеджером — кем только не работал. О спикере: Leon Fayer родился в когда-то дружественной республике, но вырос в США. Участвовал в стартапах — некоторые были более удачные, а некоторые не очень.

Эта компания специализируется на разработке масштабируемых систем, поэтому Леон имеет уникальную возможность проектировать и строить системы для самых посещаемых сайтов в мире — Wikipedia, National Geographic, White House, MTV и т.д. Много лет Леон работает в OmniTI.

Для каждого человека ответ будет разный. Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас.

Вы больше Dev, чем Ops? Если вы читаете эту статью, скорее всего, вы имеете отношение к DevOps. Для Dev и Ops определение успеха немного разное: для Dev — это, естественно, тестирование. Или, наоборот, больше Ops, чем Dev?

Тестирование

Проблема в том, что я еще и циник, и не фанат тестирования как такового. Для меня, как для программиста, успешное тестирование означает, что все в порядке, все хорошо, все работает — можно запускать в production. Не потому, что это трудно, и не потому, что это долго — а потому, что тестирование не дает то, что я хочу.

Поймите меня правильно, тестирование — это обязательный процесс, оно должно быть включено в любой проект, но его явно недостаточно, чтобы гарантировать успех.

Есть много разных вариантов тестирования:

  • performance-тесты;
  • user-тесты;
  • автоматическое тестирование…

И что, вас не будят по ночам алерты? Сколько вы используете методов тестирования — 1, 2, 3, 5? Все работает в production?

Оно предопределено: мы знаем, что поезд должен выйти из пункта А и дойти в пункт В, на это мы и тестируем. Проблема в том, что тестирование дает иллюзию успеха. Если у поезда отвалится колесо или закончатся дрова, это не будет неожиданностью. Есть варианты, которые мы продумываем. Мы не можем это тестировать, потому что мы не знаем, что такой вариант возможен. Но мы не тестируем, например, ограбление поезда.

Первая из них, естественно, проблема с данными. Есть парочка проблем, из-за которых тестирования просто недостаточно. То, что задача работает локально, но почему-то не работает в production — стандартная проблема.

Неважно, сколько репликаций мы делаем вживую —development и production никогда не будет равен. Неважно, насколько мы стараемся. Будет ли еще одна строка в базе данных, будет ли еще один лишний запрос — в production всегда будет что-то, на что мы не рассчитывали.

Wolfe+585 — самая длинная фамилия в мире:

Hubert Blaine
Wolfeschlegelsteinhausenbergerdorffwelchevoralternwaren-gewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzen-vorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahres-vorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinund-siebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartsein-langefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchege-habtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandig-menschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhe-mitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum,
Sr.

Я знаю минимум 5 разных точек, в которых может полететь вся система.
Немногие системы выдержит, если кто-то введет такую фамилию в форму.

Поэтому вторая проблема — это проблема с пользователями.

Если бы не было пользователей, все было бы гораздо легче, честно скажу. Это такие интересные люди, которые поломают все, что угодно.

Даже если в вашем UI будет одна кнопка, они все равно найдут метод, как поломать то, что мы делаем.

Самый лучший пример — это World of Warcraft.

В свое время там были довольно легендарные баги. Для тех, кто не знает, — это онлайн игра, в которую играли 10 млн людей. Corrupted blood bug — это идеальный пример того, насколько пользователи все портят.

Один из новых боссов ставил проклятие на одного из 40 игроков в группе. Как и в любой игрушке, в World of Warcraft постоянно появлялся новый контент, новые идеи, новые боссы. То есть надо было отбежать в сторону — там была целая механика. Принцип проклятия был как бомба замедленного действия — оно потихоньку забирало жизни всех вокруг. И все было хорошо, пока в какой-то момент один из игроков не решил во время боя телепортироваться в город...

Мало того, там были еще неигровые персонажи, которые тоже заражались проклятьем. В городе находились тысячи людей любых уровней, самых маленьких тоже. Это стало игровой чумой в прямом смысле этого слова. В течение суток серверы опустели. Нельзя было выйти никуда, где еще были другие игроки. И все из-за одного тестировщик — даже не знаю, как его назвать. Пришлось сделать round restart всех серверов для того, чтобы убрать проклятье и поменять механику.

Мы все с этим сталкивались: API, от которого ты зависишь, вдруг перестает работать; или ты перестаешь контролировать API. Третья основная проблема — это проблема с внешней зависимостью.

Внешняя зависимость может быть не только прямая, но еще и косвенная. Но есть еще бо́льшая проблема с этим. Каждый OpenSource продукт зависит от каких-то библиот6ек, которые тоже OpenSource и которые поддерживает кто-то другой. Мы все сейчас используем OpenSource. Когда что-то ломается, оно ломается не только в этом маленьком модуле, но и во всем, что зависит от него.

Это npm модуль на node.js, который выставляет пробелы перед string (в начале строки). Наверное, самый идеальный пример этому был недавно, примерно год назад — это left-pad. Но оказывается, его включили в очень много популярных модулей. Не будем обсуждать, зачем этот модуль был сделан. В какой-то момент автор решил, что с него хватит, убрал этот модуль из npm, и полетело 70% кода, написанного на node.js.

Если вы думаете, что это единичный случай, — вы ошибаетесь.

Этот модуль определяет четное число или нет. Есть еще модуль is-odd, который и сейчас есть в npm.

Но там еще 12 модулей, которые его используют! Не будем обсуждать то, что 3 миллиона людей не знают, как проверять четность/нечетность. Если вам кажется, что в нем нечему ломаться — там 5 версий! И неизвестно, сколько этих модулей используют еще модули.

Возвращаясь к нашим баранам — есть еще много вариантов:

  • Недальновидность — мы не знаем, что будет в будущем. Y2K — это идеальный пример. Никто просто не подумал, что в 2000 году полетит все написанное в Коболе.
  • Количество вариантов тестирования.

Есть хороший пример снова с World of Warcraft — у них много хороших примеров на эту тему.

Обнаружилось, что только один вариант расы и пола не мог войти в эту пещеру — это были таурены женского пола. Спустя полгода после выхода игры, в поддержку начали приходить обращения, что в одну пещеру не могут зайти некоторые игроки.

Потому, что таурены — это вымышленная раса, смесь человека и быка. Почему потребовалось 6 месяцев, чтобы найти эту ошибку — ведь играют миллионы людей? Никто не хотел играть коровой, поэтому за 6 месяц ни один человек не дошел до максимального уровня, чтобы зайти в пещеру и найти этот баг. Таурен-женщина — это говорящая корова. Соответственно, никто его не протестировал.

  • Изменение в исходных данных. Мы действительно не знаем, что будет происходить завтра.

Но тесты не дают 100% покрытия. В любом случае тестов мало не бывает. Это постепенно подводит нас ко второй части — Ops. Поэтому тестирование не дает гарантию успеха. Для эксплуатации успех — это мониторинг.

Мониторинг

Есть много причин, зачем нужен мониторинг:

  • совершенного кода не существует;
  • системы становятся сложнее;
  • растущая внешняя зависимость;
  • упреждение -> реагирование;
  • ...

Это основная причина. Мониторинг нужен потому, что все меняется. Причем именно в production, там все меняется постоянно, и нам нужно это обнаруживать.

— Все! Что должен покрыть мониторинг? Это короткий ответ, но он должен покрыть все.

На самом деле, у нас всех есть чек-лист, что мы мониторим: Это все немного абстрактно.

  • инфраструктуру;
  • базы данных;
  • приложения;
  • точки интеграции;
  • время обработки запросов;
  • нагрузку;

Многие собирают сотни, тысячи и десятки тысяч метрик на своих системах. Там может быть миллион вещей.

Мы соберем очень много метрик для вот этого:

Это значит, что с сайтом все хорошо. Конечно, я утрирую, но все, что нам нужно с точки зрения Ops — это чтобы HTTP вернуло 200. С точки зрения Ops успех — это именно это: все графики в зеленой зоне, все работает правильно — все хорошо! Раз сайт работает, значит, базы данных работают, приложения работают — все в порядке.

Они обрабатывают 500 миллионов твитов в день —сумасшедшая цифра. Все знают, что такое Twitter.

Ошибки легендарные по своей сложности или легкости — с какой стороны посмотреть. Но они также известны своими ошибками.

Он нигде не появлялся и просто пропадал, а мониторинг показывал, что все в порядке. У них была ошибка: сайт работал, клиент мог написать твит, нажать кнопочку, ему говорили спасибо, твит отсылался — и все! А твитов нет! Сайт возвращает на запрос 200 — API работает.

Я в течение часа на трех экранах чинил проблемы, а он орал, почему ничего не работает. У меня есть любимая цитата одного заказчика. Когда я пытался объяснить, какие проблемы я чиню, человек, который печатал двумя пальцами и не понимал, как пользоваться компьютером, мне сказал:

«Пока я продолжаю делать деньги, мне по***, что сервера горят».

В чем-то это очень правильно, и пример Твиттера это подтверждает: все метрики показывали, что все было в порядке с точки зрения разработчиков, но с точки зрения работы именно бизнеса — совсем не в порядке.

Конечно, в основном виноваты компании, которые выпускают продукты для мониторинга. Если честно, виноваты в этом мы все. Мы привыкли работать с маленькими системами — один, может быть, два сервера. Но мы тоже, потому что традиционно мы собираем системные метрики. Если они работают, значит, все в порядке.

Мы должны отслеживать работу чего-то другого. Теперь серверов у нас чуть-чуть больше, чем два, или даже 10, и просто измерять здоровье системы или здоровье программы — мало.

Мне платят за то, чтобы мои пользователи или мои менеджеры были довольны — кто-то должен быть доволен результатом. Возвращаясь к цитате — мне платят не за то, чтобы все было зеленым. Если все пользователи недовольны, никого это не волнует, что все зеленое.

Бизнес-мониторинг

Но когда все меняется, изменения влияют на бизнес: что-то поломалось — перестали приходить деньги, что-то починилось — деньги начали опять идти — прямая корреляция. Мы говорили, что мониторинг нужен, потому что все меняется. Или не влияют — но, если мы не мониторим бизнес, мы этого не знаем.

Как живой пример — график чтения кэша, знакомый всем.

И вдруг что-то случилось — причем очень серьезное. 90% времени все в порядке, почти все запросы идут в кэш. Но, если скорость загрузки для пользователей не меняется, действительно ли это проблема? Это проблема, которая должна разбудить в 3 часа ночи кого-то, кто ее решит.

Это: monitoring, logging, alerting. В английском есть термин Observability — наблюдаемость. Мы хотим наблюдать за всем — собирать системные метрики на каждом узле, если нужно. Поэтому термин мониторинг немного. Это показатель успеха. Но мониторить мы хотим именно бизнес, потому что он волнует всех.

Чтобы это сделать, мы должны:

Понять проблему — что именно нам нужно мониторить.   1.

Определить базовую линию — то есть достаточно ли того, что скорость загрузки у пользователя не изменилась для того, чтобы никто не просыпался посреди ночи, когда чтение из кэша перестало работать.   2.

Коррелировать данные — один из самых важных факторов.   3. Если маркетинг собирает данные по доходу, а вы собираете данные по серверам и не можете сопоставить эти два наблюдения, то в них очень мало смысла.

Насколько абсурдными они бы не выглядели, они все из моей жизни, и я на них потратил очень много нервов. Обычно я привожу очень много примеров.

Это была интернет-маркетинговая компания, которая отправляла много e-mail и использовала A/B тестирование. Пример: у меня был клиент со 100 млн пользователей. Для них мы собирали 6 тысяч метрик.

Звонит телефон — значит, что-то случилось. Все, как всегда, началось со звонка.

Что-то не работает. — У нас проблемы.

В чем это выражается? — ОК, что именно не работает?

— Мы стали получать меньше дохода.

— И?

— Что-то не работает в системе.

Если меньше доход — поговори со своим отделом продаж. — Не понял. Зачем ты звонишь мне?

— Нет, я уверен, что это что-то в системе не работает!

— Хорошо, давай посмотрим.

На графике действительно видно, что в какой-то момент доходы у них упали на 15 %. Слава Богу, у нас была метрика дохода, поэтому мы могли посмотреть. Учитывая количество пользователей, это довольно существенно.

Первым делом проверяю скорость загрузки — нормальная. Ладно, надо посмотреть.

Дальше мы начали смотреть на cpu-нагрузку, на отдельные узлы, на кэши. Посмотрели на нагрузку на базу данных — все в разумных пределах, вроде бы ничего не изменилось.

Один из больших провайдеров случайно поставил их домен в black-list. Все было в порядке., пока мы не дошли до метрик e-mail рассылки. Процент их e-mail маркетинга перестал доходить до пользователей, что означает, что меньше людей: получили письма, нажали на кнопочку, зашли на сайт и что-то купили.

Вот такая корреляция!

Если бы у нас их не было, мы бы их добавили — это очень простой ответ. Нам повезло, что у нас были эти метрики.

Это как фича: сделать свой проект, поставить мониторинг — и все, мы готовы! Самая большая ошибка, которую люди делают — это считают, что мониторинг можно поставить в конце проекта.

Всегда находятся проблемы, о которых неизвестно с самого начала. Инструментовка никогда не может быть закончена. Мы не умеем предсказывать будущее и не умеем предсказывать бизнес, поэтому мы не знаем, что такое «все». Как и с тестированием — нельзя написать тесты и покрыть все, потому что ты не знаешь, что такое «все».

Это был CEO, который на конференции в Париже проснулся утром, выпил кофе, просмотрел свою почту и отчет о доходах, и позвонил мне с той же проблемой: доход упал. Абсолютно идентичный пример тому, о чем я говорю.

Меня только что транспортировали домой с празднования дня рождения — но это не важно. Я это хорошо помню, потому что у него было 9 утра, а у меня на 6 часов раньше, еще и в субботу. То есть смотрим на нагрузку на систему, на номер регистрации, на все. Так вот, в 3 утра я сажусь за компьютер, и мы начинаем идти теми же шагами.

То есть количество такое же, а процент чуть-чуть ниже. Единственное отклонение от нормы, которое мы нашли, — это ниже процент успешных авторизаций. Но все остальные технические метрики абсолютно в норме. Я знаю, что это может быть спам и т.д. Абсолютно ничего! Причем мы дошли до того, что уже чуть ли не по строкам в базе данных шли и пытались свериться — есть ли что-то, что можно глазом поймать.

Пусть сами ее решают. Просидели мы полвоскресенья, в понедельник тоже продолжили, но уже были уверенны, что проблема не техническая. И вот в понедельник я сижу на работе и мне звонит сотрудник из их бухгалтерии:

— Слушай, можешь быстренько мне помочь?

— Что нужно?

— Можешь снять значок "American Express" с сайта?

А чего вдруг? — Конечно могу!

— Знаешь, мы здесь с ними спорим, и пока мы не принимаем American
Express вообще.

— Извиняюсь спросить, а когда вы перестали их принимать?

— Перед выходными, по-моему — в пятницу или в субботу.

После этого случая мы, конечно, поставили. Ни один человек в здравом уме никогда бы не поставил сбор метрики на процент авторизаций с определенного вида кредитной карточки!

Надо сначала смотреть на бизнес, потому что все эти системные проблемы были просто невидимы. К чему я это рассказываю? Легко заметить падение дохода, а все остальное нужно отслеживать, чтобы можно было коррелировать эти данные с данными бизнеса. Они никого не будили посреди ночи, мы не видели, что это проблемы.

Успех для бизнеса

Самое важное — как это можно измерить? Для бизнеса успех может быть разным, он зависит от целей. Традиционно мы измеряем системные показатели, иногда, как инженеры, забывая, что измерить можно все, что угодно.

Кстати, я не шучу. Например, можно измерить собственный алкоголизм. Так как мы все инженеры, мой коллега решил на поставить сенсоры Raspberry Pi, чтобы посмотреть, сколько пива мы пьем и какого. У нас в офисе стоит бочковое пиво с четырьмя краниками.

И вообще мы можем посмотреть, когда народ пьет, какое ему больше нравится пиво — темное, светлое и т.д. Это выглядит как простая шутка, но на самом деле это удобно, потому что мы видим, когда пиво подходит к концу и надо заменить бочку. Кстати, пик — это мой день рождения.

Абсолютно случайно мы нашли еще одно применение этому.

К выходным потребление алкоголя обычно уменьшается, практически сходит на нет. На графике потребление пива за несколько дней и в выходные. На графике видно точное время в пределах получаса. Однажды мы приходим в понедельник, смотрим на график и видим, что кто-то в субботу выпил четверть бочки пива. Оказалось, что уборщикам, которые приходили в субботу, надо было похмелиться, вот они и похмелялись.

Шутка шуткой, но в конце концов у них были серьезные проблемы, потому что вообще плохо пить на работе, да еще и чужое пиво!

Даже эта метрика, которую мы собирали чисто для собственного фана, оказалась важной в чем-то другом. В конце концов любые метрики могут быть полезными. Деньги для бизнеса важнее всего. Но в основном действительно нужные метрики сводятся к деньгам.

Обычно критерии успеха бизнеса — это что-то, что в конечном итоге связано с деньгами:

  • прибыль;
  • доход;
  • затраты;
  • эффективность.

Бизнес метрики:

  • регистрации;
  • покупки;
  • просмотры рекламы;
  • конвертации;
  • процент возвратов;
  • количество выпитого пива

Кстати, скорее все, все эти метрики уже собираются в вашей компании — либо продажами, либо маркетингом. Все это имеет денежный эквивалент. Так что не нужно придумывать колесо, можно просто взять уже имеющиеся метрики в собственную систему.

Другие, именно технические метрики, тоже могут рассматриваться в этом контексте. Все должно рассматриваться в контексте бизнеса. Мы говорили про специальные метрики для бизнеса.

Сначала все в порядке, идет вверх — вниз, вверх — вниз, и вдруг явная проблема. Например, скорость загрузки —довольно стандартный график. Ее починили, и график вернулся к стандартному виду — 99-й процентиль ниже порога, SLA не нарушается.

Если взять тот же график и посмотреть на количество пользователей, которые были затронуты, проблема сразу смотрится по-другому.

Более того, когда никакие алерты не пришли и считалось, что все в порядке, тоже были проблемы. Эти пользователи не потратили деньги, то есть принесли убытки. Здесь это видно гораздо лучше, чем на графиках системных метрик.

Но каждый пользователь несет определенную ценность. Каждый пользователь важен. Мы это забываем, потому что мы смотрим на среднее количество на интервале времени. Сумму, которую каждый пользователь потратит в следующие 3 месяца, маркетологи очень хорошо знают. Маркетинг об этом очень хорошо знает.

Среднее величина — это зло. Не то чтобы она не нужна, она дает нам информацию, которая действительно необходима, когда мы пытаемся найти проблему, но как измерения ее недостаточно.

На графике средняя скорость загрузки.

Опять все стандартно: сначала все в порядке, потом маленькая проблема, и дальше серьезная проблема, которую кто-то решал.

Там, где график средней скорости загрузки показывает, что все в порядке, 50 % пользователей действительно попадают в категорию «все в порядке», но у остальных загрузка либо медленнее, либо вообще не происходит. Это тепловая карта, которая касается индивидуальных пользователей в каждую секунду.

Насколько ценна 1 секунда?

Мы работаем в системах десятки тысяч запросов в секунду. Сейчас мало систем с 1-2 запросами в секунду. Скорее всего, это 10 000 разных пользователей, которые могут быть как-то затронуты. Там есть 10 000 разных вариантов, что может пойти не так.

Загрузка страницы для каждого пользователя в среднем занимает 600-700 мс. Построим распределение скорости ответа на 1 секунду. Но если посмотреть детально, то видны пользователи, у которых загрузка заняла больше секунды. Конечно, 600 мс — это не самое лучшее время, но вроде бы в разумных пределах. Уже с 800 мс начинается область, где можно терять деньги, потому что пользователи будут просто уходить — грузится слишком медленно.

Если ответ вернулся за 0 секунд, явно что-то пошло не так, совсем не так! Интересно, что проблема может быть и там, где время загрузки близко к нулю. Но по среднему никакие алерты не пойдут.

Гистограммы и тепловые карты — это самый лучший способ отследить картину, поскольку они показывают разброс индивидуальных пользователей и как он соотносятся с метрикой. Каждый пользователь важен, поскольку несет какую-то сумму.

Можно посмотреть, насколько они отличаются друг от друга. На этой карте показаны 99-й и 50-й процентили, среднее и разброс индивидуальных пользователей.

Еще один момент, о котором хотелось бы поговорить — это то, о чем говорят в DevOps в последнее время — это измерение эффективности процесса.

Эффективность процесса

В каждом процессе есть много маленьких процессов, в каждой компании есть разные процессы, и каждый этап этих процессов может быть оптимизирован.

Берешь весь процесс и записываешь, что именно происходит пошагово. Value stream mapping — это разбиение процесса на составляющие и оптимизация индивидуальных шагов. После этого смотришь, где лучше всего оптимизировать этот процесс, чтобы увеличить доходы. Например, кто должен поставить галочку, где работал автоматический тест, сколько он занимает, что случается после этого, какой процент ошибок.

Есть четыре основные метрики:

  1. MTTD (mean time to discovery) — сколько в среднем нужно времени, чтобы найти ошибку.
  2. MTTR (mean time to recovery) — сколько в среднем нужно времени, чтобы исправить ошибку.
  3. Время от начала процесса до момента, когда результат приходит в руки пользователя.
  4. Время/ресурсы каждого шага.

Путем нехитрых вычислений получалось: «Если просто регистрация будет не работать час — вот сколько денег потеряет компания. На паре своих проектов, я вычислял, сколько денег компания делает в час, и потом из этого экстраполировал, сколько денег приносит один пользователь. Не теоретических или потенциальных, а физических денег теряет компания, если регистрационная страница не работает».

Это в конце концов повышает доходы компании, которые тоже нужно измерять. Если процесс можно оптимизировать, он отнимает меньше ресурсов, стоит меньше.

Мы это иногда забываем и считаем, что наша работа — в том, чтобы написать лучше программу, сделать самую прикольную архитектуру. Таким образом ваша работа заключается в поддержке бизнеса. Научитесь понимать бизнес. В конце концов все это делается для того, чтобы поддержать бизнес.

Но поймите, какие данные нужно собирать, что именно важно, что должно будить вас среди ночи. Как понимать бизнес — это отдельный разговор, который может занять гораздо больше времени, потому что мы с ними говорим на разных языках. Потому что успех для вас — это успех для бизнеса.

1 и 2 октября в Москве состоится профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf Russia.

Для продвинутых специалистов, будут доклады с глубоким погружением в тему и важными подробностям, и обсуждения новинок. Если вы только начинаете работать по принципам DevOps, это будет отличной возможностью посмотреть на реальные работающие примеры от старта и до успешного внедрения, и проникнуться такими идеями, как в докладе Леона.

Приходите и увидите, как разработка, тестирование и эксплуатация могут быть нераздельны.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть