Блог компании veeam software

В романе Марка Твена Янки при дворе короля Артура главный герой попадает, как легко догадаться, в дремучее английское Средневековье. Пользуясь своим современным школьным образованием, он значительно подталкивает технологических прогресс Англии, а заодно и сам с легкостью добивается привилегированного положения. В поезде времени мы, к сожалению, пока не научились пересаживаться из вагона в вагон. Но если бы однажды путешественники во времени всё же появились, можете быть уверены: Джон Ло почти наверняка оказался бы одним из них. Вот только в отличие от героя Твена, Ло положился не на свои знания физики, химии или астрономии. Нет, он перевернул с ног на голову всю экономику Франции, как если бы кто-то, чуть разобравшийся в истории с Wall Street и GameSpot, вдруг провалился в XVIII век и попытался втолковать местному королю про банки, инфляцию для разогрева экономики и акционерные общества. Возможно, этот кто-то так же попытался бы лично разбогатеть за счет финансового невежества окружающих, но у каждого, как известно, свои недостатки.

Эта статья об афере Джона Ло возможно, самой значимой в экономической истории. На краткий миг Ло стал самым известным, самым ненавидимым и самым влиятельным человеком в мире. Ему удалось создать первый частный банк во Франции, сделать его государственным и провернуть колоссальную авантюру с акциями, разорившую половину богатейших домов Парижа. Так кем же был этот удивительный мистер Ло и как ему удалось провернуть свою аферу?

Ло родился в Эдинбурге в семье ювелира-ростовщика. Юность Джона Ло чем-то напоминает Портрет Дориана Грея - молодой, исключительно очаровательный провинциал приезжает в Лондон и быстро окунается во все радости столичной жизни. Прозванный за щегольство красавчиком Ло, он становится известен как заядлый игрок, дуэлянт и развратник. По словам одного из друзей, В 20 лет он уже был весь хорошо знаком со всеми видами распутства. Больше, чем женщин и карты, Ло любит только одно банковское дело.

В Лондоне все идет отлично, пока Ло не убивает одного парня на дуэли. Скрываясь от тюрьмы, он устраивает себе небольшой Евротур через Голландию (где изучает знаменитый Амстердамский банк вы же помните фильм Тюльпанная лихорадка? Голландия рай для фанатов банков), Францию (где приобретает уже не знания о банках, а общество прекрасной замужней дамы, которая станет его верной спутницей), Италию (где он вновь играет, и весьма успешно), и, наконец, обратно на родину в Шотландию. Там он отчаянно пытается добиться двух вещей: помилования, что логично, и возможности реализовать свою систему. А система Ло была простой и красивой.

У Ло была очень простая идея для экономики нужны деньги. Да-да, знаю, шок контент. Деньги это что-то вроде смазочного механизма финансовой системы. Если их не хватает, весь механизм встает. Вам нечем платить работникам, им нечем платить лавочникам, лавочникам нечем платить налоги ну вы поняли. No money no honey. Во времена Ло деньги были в основном металлическими старое доброе золото и прочие, менее благородные металлы. А количество металлических монет ограниченно. Поэтому Ло и говорит: а давайте использовать бумажные, кредитные деньги. Откуда же мы их возьмем? спросят его жители XVIII века. Так напечатаем, ответит Ло. Система Ло стояла на 3 трех китах:

1. Экономику можно подтолкнуть с помощью бумажных денег.

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

3. Банки должны проводить политику кредитной экспансии. Сейчас объясню, что это.

Кредитная экспансия это когда банк дает ссуд больше, чем у него есть золота (или иных металлических, то есть настоящих денег). Например, вы с друзьями решаете открыть банк. Вы наскребаете миллион фунтов стерлингов да не бумажками, а золотом. Это ваш уставной капитал, реальные деньги, которые есть у вашего банка. Каждый знает, что деньги нужно хранить в сберегательных кассах, так что люди несут свое золото к вам на хранение они открывают в вашем банке вклады. Скажем, еще на миллион. А вы тем временем печатаете банкноты.

Тут вы можете меня с чистой совестью остановить и спросить: а что вообще такое эти банкноты? Всё очень просто.

Что такое банкноты (коротко)

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

Спустя пару дней Петя обнаруживает, что спиннинг его мечты продается с серьезной скидкой. Акция действует всего два дня, а ему, как назло, не хватает пяти тысяч. Тогда он идет к своему другу Саше и просит у него 5 000 тысяч в долг. Петя тоже честный человек, так что он тоже пишет расписку Я, Петя Иванов, взял в долг у Саши 5 000 рублей и верну их до 15 марта 2021. Если не верну, он может забрать себе мой спиннинг.

Возможно, вы когда-то слышали слово вексель. Так вот, вексель это долговая расписка, вроде тех, что дали вы с Петей.

Петя отдает Саше расписку и вдруг понимает ему должны 5 000 до 15, и он должен 5 000 до 15. По сути он просто возьмет деньги у вас и передаст их же Саше. Так почему бы не убрать лишние сущности из этого уравнения и не передать вашу расписку Саше? Так появляется переводной вексель. Играли в переводного дурака? Тут всё работает примерно так же. Теперь вы, Вася, должны напрямую Саше, а Петя может идти рыбачить с чистой совестью.

Но Саша может сказать: Позвольте-ка. Я этого вашего Васю знать не знаю. Посмотрите на его расписку вот он говорит, верну до 15 марта. Но какого года? И кстати, 5 000 чего? Белорусских зайчиков? Да и вообще, эта расписка написана на салфетке. Нет, так не пойдет. Я не могу ей верить. Значит, нужна некая стандартная форма расписок. Саша может так же заметить: Ну ладно, Петя мой друг, если что, я могу у него свои деньги потребовать назад. А Вася-то кто? Как, если что, я его буду искать? Вместо неизвестного Васи куда лучше подошел бы богатый и респектабельный человек, который мог бы погасить долг и которому Саша мог бы доверять. Тут на сцену выходит банк.

Вы приходите в банк со своей распиской на салфетке, банк ее забирает и дает вам официальную расписку от имени банка. Эту расписку вы даете Пете, а тот передает ее Саше. Теперь вы должны банку, а банк должен Саше. Долговая расписка от имени банка это и есть банкнота.

Если банк респектабельный, известный, ему многие доверяют, то его банкноты достаточно быстро начинают вести себя как обычные бумажные деньги, знакомые нам с вами. Например, идет Саша мимо винотеки и видит бутылочку отличного вина. Он подходит к продавцу и говорит: К сожалению, у меня нет сейчас денег. Но банк должен мне 5 000 рублей. Смотрите, вот его расписка. Продавец узнает название банка да, это старое, уважаемое заведение, оно всегда держит свое слово. Он с готовностью обменивает вино на банкноту, а потом идет в банк и получает реальные деньги. Или передает эту банкноту своему поставщику в обмен на сыр.

Впервые банкноты в Европе выпустил Стокгольмский банк в 1661 году. Банкноты всем очень понравились в то время в Швеции деньги были серебряными и медными, и вес слитков мог доходить до 20 килограммов. Намного удобнее носить с собой бумажку с надписью 10 риксдалеров, чем возить на тележке такую гирю. Кроме того, в те времена, когда деньги были все еще металлическими, большой проблемой была порча монеты купцы, ростовщики, находчивые лавочки и вообще все, кому не лень, то и дело норовили переплавить золото, смешав его с медью, например, или отрезать от монеты крохотный кусочек, и потом эти крошки слепить в какое-нибудь колечко и продать в ювелирной лавке (для борьбы с этим монеты стали чеканить с ребристыми краями так было легче заметить, если от одного из них отрубили кусок). Но вернемся к нашему банку и Джону Ло.

Что предложил Ло

Итак, вы напечатали и выдали миллион банкнот, по фунту стерлингов каждая. Это значит, что вы дали расписок на миллион фунтов. С каждой такой распиской к вам может прийти в банк человек и обменять ее на реальные золотые монеты. Ваш уставной капитал тоже миллион фунтов, так что у вас всё в порядке. Даже если все держатели банкнот в один ужасный день решат прийти к вам за золотом всей толпой, ничего страшного не случится.

Но тут появляется Джон Ло и говорит:

- Один миллион банкнот это, конечно, хорошо, но знаете, что еще лучше? Пять миллионов. Или даже десять. Десять это круто, давайте напечатаем десять! Представьте себе, сколько кредитов для бизнеса вы сможете выдать, фермер закупит семян и вырастит кучу пшеницы, кондитер купит муки и напечет полный дом эклерчиков, и все они фермеры, пекари, токари, кузнецы и торговцы смогут нанять больше людей, заплатить им, и эти люди тоже будут покупать и тратить. Металлические деньги это варварский пережиток, связывающий нас по рукам и ногам! Поршни экономики застучат быстрее, если мы подкинем в ее печку немного угля то есть банкнот

Тут, правда, вдохновенные мечты Ло мог бы прервать противный голосок, интересующийся, что будет, если все держатели 10 миллионов банкнот придут в банк, у которого есть только 1 миллион своих денег и еще миллион чужих вкладов, которые временно можно запустить в оборот. Но Ло от этого голоса отмахивается банк заморозит выплаты или просто лопнет. Кому какое дело до таких мелочей, когда он говорит о новой системе, новой экономике, новом мире тебе денег, тебе денег, всем денег и пусть никто не уйдет обиженным. Его глаза горят, а в голове уже проносятся картины прекрасного будущего (мы, кстати, в этом будущем живем, поздравляю).

Свою гениальную идею радикальной кредитной экспансии Ло сначала предложил родной Шотландии, одновременно продолжая просить Англию забыть про давнюю дуэль так сказать, ну было и было, пора двигаться дальше. В Шотландии идеи Ло особого восторга не вызвали, и что еще хуже, на горизонте замаячило объединение Англии и Шотландии, а с ним и опасность, что за совершенное в Лондоне преступление Ло могут теперь посадить и в новом союзном государстве. Так что Ло подтягивает носки повыше и бежит обратно на континент. Там он продолжает весьма успешно играть, и в итоге оседает в Париже с солидным состоянием в 1600 тысяч ливров большие деньги по тем временам. Именно в Париже Ло и провернул свою знаменитую аферу да не одну, на самом деле, а сразу две.

Ло покоряет Париж

В начале XVIII веке Франция была не в лучшем положении. Почти все XVII столетие она провела в войнах мучительная Тридцатилетняя война с Англией, разорительные морские сражения с Голландией, не говоря уже о мелких стычках и надоедливых берберских пиратах так что к началу XVIII века Франция подошла с колоссальным государственным долгом. Основным видом госзайма в то время во Франции была рента, отсюда и знаменитое слово рантье, то есть владелец ренты. В начале XVIII века процент дохода по ренте несколько раз снижали, рантье выли, но госдолг и не думал сокращаться. Тут в захлебывающейся в долгах Франции появился Джон Ло.

Красавец, игрок и авантюрист, он быстро подружился с герцогом Филиппом Орлеанским и поделился с ним своими идеями о том, как вытащить Францию из долговой ямы. Мысль Ло была прежней есть внутренний долг, и он всё растет. Так давайте просто сделаем банкноты, которые все в стране станут принимать за деньги, и потом напечатаем таких банкнот очень, ну просто неприлично много. И покроем долг. Филиппу эта мысль понравилась и, став регентом короля в 1715 году после смерти Людовика XIV, он тут же передал Ло бразды финансового правления. Ло без дела не сидел и в 1716 году основал первый частный банк во Франции, назвав его скромно Всеобщий банк. С этого всё и началось.

С самого начала банк отражал авантюрные идеалы Ло уставной капитал только на четверть состоял из реальных металлических денег, остальные 75 процентов обеспечили государственными ценными бумагами (которые из-за долга были не очень-то ценными, скажем честно). Банк не платил налогов с прибыли иначе в чем смысл быть другом регента короля? Кроме очевидного хранения вкладов, банк мог совершать операции с векселями, то есть чужими долговыми обязательствами, и выпускать собственные векселя - банкноты, которые обменивались на реальные металлические деньги экю по номиналу, написанному на этих банкнотах. Забавный факт во Франции оборот и использование векселей в те годы были платными нужно было заплатить определённый процент с дохода или фиксированную сумму за проведение операции. А вот банкноты Всеобщего банка можно было использовать без всяких дополнительных платежей они были беспроцентными. Кроме того, они были еще и анонимными, то есть действовали на предъявителя. Наконец, государство даже разрешило платить налоги банкнотами этого нового частного банка. Абсолютная власть французского монарха оказалась последним, необходимым элементом системы Ло.

Поначалу всем парижанам (а затем и французам вообще) новый банк очень понравился бесплатные и понятные векселя, банкноты с фиксированной суммой обналичивания (сколько на бумажке написано, столько золота вам и дадут, удобно), анонимность и, наконец, широта использования банк был при короле, ему доверяли, значит, банкнотами можно было платить везде. В 1718 году банк перестал скрывать очевидное и официально стал Королевским. До этого знаменательного преобразования банк успел напечатать банкнот на почти 150 млн ливров, из которых больше 100 миллионов уходило на покрытие государственного долга. Дуэт Ло и Филиппа Орлеанского, казалось, ведет Францию к светлому будущему. Ло, тем временем, придумал кое-что покруче банка он объединил колониальные компании Франции в Вечную Компанию Всех Индий, в историю вошедшую как Миссисипская, по имени главного региона, где должны были появиться процветающие колонии.

В то время в Европе колониальные компании уже не были чем-то новым. Обычно государство даровало им право на монопольную торговлю с колониями взамен на обещание основывать и развивать эти самые колонии. Самыми известными были тогда Британская и Голландская Ост-Индские компании, торговавшие с восточными странами, однако постепенно разгонялась и колонизация запада, который, вслед за ошибкой Колумба, по привычке величали Западной Индией (потому и компания Ло занималась Всеми Индиями - то есть и восточными азиатскими, и западными американскими колониями). И в колониальной компании Ло предложил новую идею в отличие от консервативных англичан и голландцев, чьи компании были, по сути, объединениями купцов, каждый из которых вкладывал существенную долю капитала, Ло сделал акции Миссисипской компании доступными широкому кругу лиц и всячески поощрял их активную торговлю на бирже.

Акционерные компании, если очень просто, возникают, когда группа лиц договаривается сделать что-то вскладчину. Например, вы решаете выкопать в вашем садоводстве скважину. Скважина стоит дорого, скажем, 200 тысяч, но позволит потом продавать окружающим воду. Поэтому вы еще с 3 соседскими участками скидываетесь по 50 тысяч. Теперь вы держатель 25 процентов акций компании Скважина и будете получать 25 процентов от доходов вашего небольшого водного предприятия. Акционерные компании штука исключительно древняя, археологи находили клинописные таблички из Древнего Вавилона, на которых было зафиксировано право на доход акционеров. Особенно акционерные компании начинают расцветать в Европе в период колонизации, поскольку собирать флот и зачищать чужие берега от слоновой кости удовольствие дорогое. Обычно акционерные компании включали узкий кружок по интересам вы и ваши соседи, вы и еще парочка богатейших купцов и т.д. Но Ло решил сделать акции своей гигантской торговой компании общедоступными.

Главной функцией Компании Миссисипи была консолидация, то есть объединение разрозненных французских торговых колониальных компаний и, что куда важнее, всё того же государственного долга Франции. Многие французские колонизационные компании на тот момент успели стать убыточными, а шаг Ло позволил перевести их финансирование из казны в одно частное акционерное общество. Объединив торговые компании, Ло стал активно рекламировать свое новое замечательное предприятие. Он рассказывал всем о том, насколько прекрасна и богата Северная Америка, запустил в печать газеты и брошюры, в которых Миссисипи и рай оказывались удивительно похожи, а также всячески призывал рантье отказаться от своих пыльных рент и приобрести акции своей компании. На деле компания владела несколькими дюжинами дышащих на ладан судов, а Ло отчаянно слал в Америку иезуитов, чтобы хоть как-то приблизить реальных индейцев к рекламным проспектам, рисовавшим картины местного населения, на носилках тащивших к кораблям золото, драгоценные камни и женщин.

Для того, чтобы подогреть интерес, Ло демонстративно купил две сотни акций собственной компании. Каждая акций была 500-ливровой, однако пока на рынке стоила лишь 250. Ло публично пообещал через полгода купить каждую из них за 500 ливров, то есть по номиналу, в независимости от того, какой будет рыночная цена. Сейчас мы бы назвали такую сделку фьючерсной. Во времена Ло ее бы могли назвать гениальной. Реклама, ажиотаж, меры государственной поддержки, наконец, близость самого Ло к регенту короля сделали свое дело и акции стали стремительно набирать популярность. Когда через полгода Ло, как и обещал, уплатил по 500 ливров за акцию, рыночная цена превышала номинал и Ло неплохо на этом заработал.

В Париже началось оживление, поршни экономики застучали быстрее. Цена на акции компании Ло росла, все хотели их купить, чтобы потом продать подороже. Акции выпускались ограниченными батчами, спрос превышал предложение. У порога компании стали собираться люди, ждущие очередного выпуска акций, очереди росли, стали составлять списки, перечни и подписки. Прошло всего два года с основания компании, а в 1719 году ее акции те самые, что демонстративно купил Ло, с номиналом 500 продают уже за 5 тысяч ливров. Истерия начинает охватывать весь Париж, от лавочников и кучеров до самых высших слоев. В Париже нет человека важнее, любимее и желаннее, чем Ло, все хотят попасть к нему на прием, лично отблагодарить человека, сделавшего их в одну ночь богачами. Как писала матушка Филиппа Орлеанского: Одна герцогиня публично целовала ему руки.

Акции, как и банкноты Королевского банка, анонимные, на предъявителя. В Париже появляются банды, охотившиеся на держателей акций. На рю Кенкампуа, что недалеко от Лувра, возникает стихийная биржа, где желанные акции Ло продают по 20 тысяч ливров за 500-ливровую акцию. Это огромные деньги! И, конечно, никто в здравом уме не стал бы вести такие расчёты в золоте, верно? Это же килограммы и центнеры! Поэтому акции покупают за банкноты банкноты Королевского банка того же Ло, которые он стремительно печатает параллельно с акциями. Начиная с 1719 года печатный станок работает без передышки, к весне 1720 года Ло успевает напечатать банкнот в два раза больше, чем было во всей Франции денег до открытия его банка. Но новых банкнот едва хватает для покупки новых акций только за два последних месяца 1719 года Ло выпускает 640 тысяч акции тысячного номинала. Все хотят акции Ло, и всем для этого нужны банкноты Ло. Люди взлетают на вершины финансовой лестницы, впервые начинает использоваться слово миллионер. В 1720 году Королевский банк и Компания всех Индий официально объединяются, Ло назначают генеральным контроллером финансов, вся экономика Франции теперь в его руках. И тут система начинает потихоньку сыпаться.

Ло разоряет Париж

Первыми это замечают братья Пирс заклятые враги Ло с тех самых пор, как тот оттеснил их с теплого места откупщиков податей. Они видят главный, очевидный изъян в плане Ло банк выпускает банкнот больше, чем может обналичить. Пирс начинают массово скупать банкноты Королевского банка и требуют обменять их на золото. Простые люди тоже замечают, что что-то не так безумный печатный станок Королевского банка напечатал слишком много банкнот, инфляция залила Париж. Цены выросли почти на 90%, люди ломанулись в банк в попытке обменять стремительно обесценивающиеся бумажки на реальное золото. Но финансы Франции теперь это Ло, и в феврале 1720 года он запрещает хранить дома больше 500 ливров. Значит, всё остальное придется держать в банкнотах, а если у вас на руках остались только банкноты, то больше, чем на 500 ливров золота вам их не обменять. Золото запрещают вывозить из страны, в домах начинаются обыски если вы храните больше 500 ливров, излишек конфискуют. В марте Ло запрещает использовать золото, в сентябре серебро, хождение монеты во Франции остановлено. Остались только банкноты. На бирже начинается паника.

Париж теперь не просто оживлен, его лихорадит. В марте запрещают уличную торговлю акциями, но кризис уже не остановить Ло полностью потерял доверие населения, все мечтают избавиться от акций его компании, цены на них обваливаются. Следом и банкноты королевского банка стремительно теряют свою ценность, к осени их соглашаются принимать только за четвертую часть номинала. В Париже начинается голод, под окнами компании Ло собираются толпы недовольных сохранились записи о том, что в один день собралось 15 тысяч разъярённых владельцев акций. Ло приходится прятаться во дворце Филиппа Орлеанского. Вскоре Филипп признает, что Королевский банк обанкротился, его банкноты теряют всякую юридическую силу банк не в силах выплатить свои долги. Имущество Ло конфискуют, сам он бежит заграницу, а через три года приходит печальная весть герцог Филипп Орлеанский умер. Больше надежд на возвращение во Францию нет. Ло, впрочем, не унывает он немного путешествует по Европе, успевает поработать чем-то вроде шпиона Англии в Германии, и в итоге оседает в Венеции, где продолжает играть, пишет монументальную Историю финансов времен регентства и делится со всеми желающими своими идеями о силе кредитной экспансии и торжестве банкнот над варварскими металлическими деньгами, которым остался верен до самой смерти.

Франция долго приходила в себя. Понадобилось почти полвека, чтобы французы снова оказались готовы основать один большой банк, да и то назвали его Учетная касса - от греха и дурных ассоциаций подальше. Лихорадка Ло стало разорением для множества людей от обычных горожан до великосветских особ. Но те, кто вовремя почувствовал приближающийся обвал и смог продать акции на пике, а потом вовремя обменять банкноты на реальные ценности, нажили огромные состояния, появились новые олигархи. Луи-Анри, герцог Бурбон, после смерти Филиппа Орлеанского ставший первым министром Франции, например, не только успешно спекулировал акциями на их пике, но и смог вывести свои доходы и перевести их в материальные ценности, заработав на афере Ло около 25 миллион ливров. Полный обвал доверия к госбанку позволил возвыситься и частным банкирам, которые отныне вели дела правительства и короля.

Прочитав историю авантюр Джона Ло, вы могли задаться вопросом Но ведь это всё было немного незаконно? И под немного я имею в виду абсолютно и совершенно точно незаконно. Ему удалось это провернуть только из-за того, что в абсолютной монархии король может делать всё, что хочет? Не совсем. Несмотря на сотни разоренных дворян, потерявших свои имения, скандал на всю Европу и колоссальные долги среди всех сословий Франции, от простых прачек до министров, Ло не был аферистом в смысле законности, ибо он не делал ничего незаконного просто потому что он был первым, и законы против подобных предприятий появились позже Ло (и во многом из-за Ло). Это как с пометкой в инструкции по микроволновкам не класть внутрь кошек. Прежде чем она появилась, должно было что-то случиться. В мире акций и банков случился Джон Ло. Любопытно, кстати, что примерно в те же годы в отвергшей Ло Англии происходила похожая авантюра но в куда меньших масштабах и с куда более скромными последствиями. На Туманном Альбионе ноздря в ноздрю с Ло шел еще один шотландец Уильям Патерсон. В 1694 году в Лондоне по его проекту был основан английский банк, а затем Патерсон сделал что-то очень нам знакомое он протолкнул через Парламент создание Шотландской компании. Это была да-да, вы уже догадываетесь торговая компания, занимающаяся колониями и выпускающая акции, покупать которые и агитировал Патерсон. Шотландцы накупили акций на 400 тысяч фунтов, а потом оказалось, что со своими колонизаторскими функциями компания не справляется, экспедиция практически полностью сгинула в Панаме, и все вложения сгорели. И всё же, в отличие от системы Ло, Шотландская компания не привела к краху всей экономики страны. Не оказала такого разрушительного эффекта и Компания Южных Морей в Англии, чьи акции за первую половину того же злополучного 1720 года подскочили почти в десять раз. Банковская лихорадка как лесной пожар пробежалась по всей Англии, однако к краху системы тоже не привела поскольку Английский банк не был так тесно связан с акционерными обществами, как банк Ло. Зато, пока их рынок лихорадило, англичане заметили, что структура таких биржевых афер, когда новые акции выпускаются, чтобы частично погасить долги по предыдущему выпуску акций, напоминает то, как ребенок выдувает один мыльный пузырь за другим. Так в 1720 году появился Bubble Act, вводивший обязательную государственную проверку и регистрацию компаний перед тем, как они могли продавать свои акции. Во Франции схему Ло называли выпуском дочерних, внучатых и так далее акций. В России мы называем такие схемы финансовыми пирамидами.

Авантюра Джона Ло стала одной из самых значимых в экономической истории. Она наглядно показала всей Европе, что такое инфляция (и почему нельзя просто взять и напечатать побольше денег), к чему приводит паника на бирже и в чем опасность акционерных обществ. Показала, но не расхолодила. Мы живем в мире, о котором так мечтал Джон Ло, с кредитной экспансией, отвязавшись от варварского золотого стандарта, в мире, где каждый может торговать акциями, где один твит Илона Маска может сделать держателя dogecoin богачом, как раньше один рассказ Джона Ло о колониях мог принести герцогу Бурбону миллионы. Ключевым моментом системы Ло был не обман, а доверие. Банкнота это просто долговая расписка, это обязательство выплатить тому, кто принесет ее в банк, указанную на ней сумму. В такой системе всё держится на уверенности, что банк сможет выполнить свои обязательства. Хотя современная финансовая система куда сложнее той, что была в XVIII веке, её суть остается прежней всё дело в доверии. Мы покупаем не акции, облигации или валюту. Мы покупаем и продаем уверенность в будущем компаний или экономических возможностях стран.

На эту статью меня вдохновила история с GameSpot стоило ей разразиться, как посыпались комментарии о том, что всё, наступил конец финансового рынка as we know it, или, как минимум, крупным биржам во главе с Wall Street предстоит пройти через суровые испытания и вернуться к нам обновленными, очищенными и честными. Эти комментарии наполнены праведным негодованием по поводу жадности и бесчестности современных финансовых воротил, они аплодируют ребятам с Reddit, как толпа могла аплодировать Давиду, свалившему Голиафа. Нам нравится победа маленького человека над бездушной финансовой машиной, и реддиторы в народной молве превращаются в современное переложение истории о Робин Гуде, боровшимся с шерифом из Ноттингема. Но Робин Гуд был не символом конца всей системы налогообложения, а всего лишь физическим воплощением идеи о прогрессивном налоге. Так и ситуация с GameSpot не противоречит современной финансовой системе, а, напротив, служит отличным примером ее работы. Козырем Reddit стало доверие сплотившихся частных инвесторов, но ведь доверие и есть краеугольный камень современных финансов. Так что реддиторы не сломали систему они просто вступили в игру, следуя ее правилам, как когда-то сделал и Джон Ло.

P.S. Если вам понравилась эта статья, возможно, вас заинтересуют эти книги:

1. Аникин А.В. Юность науки. Это замечательная книжка, где понятным языком и с отличным юмором рассказывается про основные экономические идеи до Маркса. Книжка была написана в СССР, так что будьте готовы иногда встретить внезапную цитату из Ленина или Маркса это было, считайте, обязательным к исполнению правилом в советской экономической литературе, и не выкидывать же теперь все хорошие отечественные книжки ?

2. Хайлбронер Р. Философы от мира сего. Не менее крутая книжка, в которой Хайлбронер сосредоточился на нескольких наиболее значимых фигурах в экономической науке Смите, Шумпетере, Марксе, Кейнсе и т.д. (Кейнса, кстати, называли Джоном Ло ХХ века). Про самого Джона Ло тут нет, но есть куча других отличных сюжетов из истории экономики и экономической мысли. Вы узнаете, кого из экономистов будили каждое утро со словами: Вставайте, граф, вас ждут великие дела (и почему это не очень хорошая идея с точки зрения душевного здоровья), кто любил разговаривать сам с собой во время прогулок, и почему призрак Мальтуса мог бы осудить создание Tinder.

3. Мисько О., Дружинин Н. Учебник по Экономической Истории. Если в этой статье вам понравились не шуточки, а суровые факты обратите внимание на этот учебник. Он совершенно монументальный в изложении экономических деталей всё, что вы всегда хотели узнать, но боялись спросить о латифундиях, прядильных машинах, денежной системе Египта временем Нового царства и еще многом другом.

Автор: Татьяна Шишкина (Veeam), по совместительству преподает на факультете Свободных искусств и наук СПбГУ

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

Я начал заниматься базой знаний, будучи зеленым джуном, так что все описанные в посте рекомендации применимы даже в том случае, если у вас нет административных или финансовых ресурсов. Иными словами, советов в духе "просто заставьте всех писать и штрафуйте непослушных" тут не будет, мы пойдем другим путем.

Про меня и мою базу знаний

В людях живал свету видал: топор на ногу обувал, топорищем подпоясывался

Ahoj. Меня зовут Коля, я QA тимлидер в компании Veeam. QA в нашей компании включает в себя не только тестирование, но и обеспечение качества в самом широком смысле. И среди этих смыслов затесалась такая штука, как управление знаниями. Я занимаюсь внутренней корпоративной базой знаний компании практически с самого ее появления, при этом поддержка базы знаний не входит в список моих обязанностей: это скорее что-то вроде pet-проекта. Долгое время у вики был статус поделочки, а мои попытки навязать вики коллегам приводили лишь к пополнению корпоративного стикер-пака моей фотографией.

Впрочем, время идет, времена меняются. Сейчас вики насчитывает 700 пользователей, 11 000 страниц, 56 000 правок и 688 000 слов (примерно полтора романа "Война и мир", если говорить только о тексте). Всего-то в 2 000 раз меньше русскоязычной Википедии, и это при условии работы на исключительно добровольных началах: никто не принуждает сотрудников пользоваться нашей вики.

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

Общий подход

Ищи себе прибыли, а другому не желай гибели

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

Главный совет, который я бы хотел дать в этой статье, звучит так: относитесь к проекту базы знаний как к публичному проекту. Скажем, если бы вы придумали Википедию или Хабрахабр, как бы вы продвигали их в массы? Реклама? Уникальный контент? Холодные как хвост вашей бывшей звонки на случайные номера из телефонной книги? Возможны любые варианты продвижения, но не забывайте адаптировать их к реалиям вашей компании и вашего коллектива. А еще не забывайте, что в случае недобросовестной рекламы коллеги узнают, где вас найти. Не перегибайте палку.

Кроме прочего, подход к вики как к публичному проекту позволяет проще относиться к проблеме продвижения. Я часто слышал обиды и сетования, что, мол, коллеги не делятся знаниями, не пишут внутреннюю документацию. Но вы же не обижаетесь на пользователей за то, что они не скачивают ваше приложение или не покупают ваши чудо-подушки за $9,99? Вы ищете способ понравиться вашим пользователям, ищете путь к их теплокровному сердцу, а не способ подчинить их вашей воле.

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

Собирайте статистику

Красна птица перьями, а человек знанием

А начнем мы с того, что нам нужно как-то оценивать качество тех способов продвижения, что мы будем пробовать. В связи с этим первое, чем стоит озаботиться это сбор статистики. Скажем, я пользуюсь Matomo (которые раньше звались Piwik), но похожий функционал есть у десятков аналогов.

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

Помимо оценки эффекта продвижения, статистика предоставляет и пачку других плюшек:

• Анализ поисковых запросов решает сразу несколько проблем:

  • Вы понимаете, что людям интересно, что они хотели бы видеть на вики. Если у вас нет статей по теме, которая интересна вашим коллегам, это отличный повод их туда добавить.

  • Кроме того, так вы можете понять, хорошо ли работает поиск, показывает ли он в поисковой выдаче правильные статьи. Если нет, то, возможно, стоит доработать поиск: убрать из индексинга ненужную информацию или добавить дополнительные ключевые слова в статью. А в особых случаях, возможно, имеет смысл задуматься о смене поискового движка.

• Можно добавлять логирование конкретных действий, что позволит вам узнать, как часто пользуются тем или иным функционалом. Так вы не будете вкладывать силы в то, чем абсолютно никто не пользуется. И сможете продвигать базу знаний, подчеркивая в обсуждениях объективно самые популярные фичи.

Накопите критическую массу знаний

Там хорошо, где нас нет

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

Вполне возможно, что информация о продуктах, технологиях и фичах уже есть где-то, но в разрозненном неструктурированном виде: почтовые треды, сообщения в Slack/Teams, сетевые папки десятилетней давности, Sharepoint-ы, осколки прошлых неудачных попыток завести единую базу знаний и так далее.

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

Еще один очевидный источник контента ваши личные заметки и ваши личные знания. Об этом аспекте давайте поговорим поподробнее.

Вам надо вот сами и пользуйтесь

Не ищи в селе, а ищи в себе

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

Проанализируйте свои потребности: какая информация вам нужна в работе, какие знания значительно ускорили или улучшили бы вашу работу. Информация о сфере ответственности или компетенциях коллег? Детальные описания фичей и внутренних API? Правила оформления отпуска и процедура выпуска релиза? Найдите удобный способ хранить и обновлять информацию такого рода, поделитесь этим с коллегами. Наверняка это было не только вашей болью, но и их тоже.

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

Сделайте вики единой точкой доступа для поиска любых знаний

И чтец, и жнец, и на дуде игрец

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

• Можно сделать просто каталог внутрикорпоративных сайтов (привет, девяностые). Да, подход, мягко говоря, не самый свежий, но и у вас в компании скорее всего не тысячи порталов. Для пары десятков сайтов и каталог обычно подходит неплохо.

• Или же можно идти по пути Гугло-поисковика и встраивать себе поиск по другим сайтам. При этом необязательно писать свой краулер, можно обойтись и более дешевым решением. Например, воспользоваться поисковым API сторонних сайтов и выводить результаты поиска по другим сайтам, если на вашей вики результатов не нашлось.

При этом не забывайте, что поиск "любых знаний" не ограничивается знаниями техническими. Такие вещи, как процедуры оформления отпусков или контакты HR/бухгалтерии/охраны/etc могут оказаться не менее важной частью вашей базы знаний, чем описания фичей или продуктов.

Создавайте зону комфорта для окружающих

Не хвались теплом в нетопленой избе

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

• Сделайте удобную главную страницу. У проектов Викимедиа особый подход к главным страницам, но мне он не нравится: их главные страницы перегружены информацией, они вызывают ужас и непонимание у неподготовленного пользователя.

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

• Стандартизируйте и упростите процесс документирования типовых вещей. Формы и шаблоны позволяют не думать про форматирование и сосредоточиться только на содержании.

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

• Долго время на моей вики не было визуального редактора: его настройка для приватной MediaWiki на тот момент была делом нетривиальным, и руки у меня до него не доходили. Когда же наконец визуальный редактор появился, ежемесячное число новых статей увеличилось в полтора раза.

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

• Моя любимая история про поиск. В Veeam используется невероятное количество внутрикорпоративного жаргона, равнодалекого от русского и английского языков. Звучать оно может примерно так: "Задизейбли шедул джобы и чекни базу вана, висит ли флаг". Адаптация к жаргону проходит не очень быстро, но это полбеды. Беда в том, что у разных отделов может отличаться терминология, так что не всегда мы понимаем друг друга. А еще мы почему-то очень любим трехбуквенные аббревиатуры, которых накопилось, наверно, больше сотни (и которые не всегда просто расшифровать).

  В базе знаний этот вопрос решился введением постоянно пополняемого словаря синонимов, аббревиатур и прочего. Словарь используется при поиске, так что пользователь всегда видит, что, например, по запросу "data mover" находится "VeeamAgent" компонент. Составлять словарь приходится вручную, так что иногда доводится выбираться в лингвистические экспедиции для сбора материала в соседние отделы.

  Конечно, остается проблема с тем, что одно и то же слово может означать сразу несколько вещей (скажем, "бекап" это резервная копия, задание резервного копирования, процесс резервного копирования, продукт Veeam Backup & Replication или отдел Backup QA в зависимости от контекста). Это пока что решаем по аналогии с Википедией: создаем страницу с термином и расписываем, что этот термин может значить.

• На большой Википедии вместе с каждой страничкой создается страница для обсуждения. Я же со своей вики все страницы обсуждения убрал: на мой взгляд, реализация дискуссий на Википедии очень плохо подходит для внутрикорпоративных дискуссий. Куда лучше заставить людей пользоваться привычными средствами ведения дискуссий: почта, чаты и звонки в MS Teams. И вопрос решается быстрее, и негатива меньше.

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

Рассказывайте о новостях

Из серебряных речей пулю не отольешь

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

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

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

• Заведите дайджест в почте, в котором вы периодически будете рассказывать о разработке базы знаний: что появилось нового, что починили старого, куда двигаетесь дальше. Если не перебарщивать с письмами, это может быть весьма действенным инструментом продвижения.

• В группах по фиче/продукту/проблеме рассказывайте о новых статьях по теме, написанных вашими коллегами. Русскоязычные айтишники скромный народ, мы обычно не любим хвастаться плодами своего труда. Сделайте это за них: во-первых, авторам будет чертовски приятно, а во-вторых, это будет поводом ввернуть пассаж про важность, пользу или даже просто про существование базы знаний.

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

Угрозы, вымогательства

Воруй любовь, убивай скуку

Писать сложнее, чем читать. Знаю это по себе, ведь эту статью я собирался написать еще два года назад. Поэтому для того, чтобы мотивировать людей не только читать, но и писать, придется заморочиться чуть больше. Что у нас есть в арсенале?

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

  Расскажите про пресловутый bus factor и проиллюстрируйте примером, ведь наверняка вы с этим уже сталкивались на практике (надеюсь, впрочем, что не в такой трагичной форме).

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

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

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

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

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

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

Играйте на здоровом самолюбии

Птицу кормом, а человека серебряной пулей обманывают

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

• Добавьте блок новостей на главную страницу, где будет информация обо всех новых правках (или хотя бы обо всех новых статьях). Рядом с именем статьи непременно должен светиться ник автора правки.

• Если вам позволяют ресурсы, можно попробовать варианты геймификации и добавить рейтинги или ачивки (например, за N статей/правок). Хотя есть мнение, что эти штуки сработают далеко не в каждом коллективе.

• У меня не было столько времени, чтобы добавлять геймификацию, но я добавил блок "Your impact" на главную страницу. Там выводится 10 самых просматриваемых статей из числа отредактированных вами, а рядом с ними число просмотров с момента вашей первой правки.

  Идея эта не моя, я подсмотрел ее на MediaWiki хакатоне в Праге, где growth team рассказывали про свои исследования аналогичной фичи большой Википедии и предлагали поучаствовать в разработке. Конечно, мне пришлось переписать фичу с нуля, поскольку у меня совсем другие источники данных, чем у Wikipedia, но в остальном я старался следовать рекомендациям Growth team.

• Маленькое расширение Thanks может послужить аналогом лайков для конкретных правок. Оно, конечно, не очень удобное, но лучше, чем ничего. И реагируют коллеги на такие "спасибо" обычно очень положительно.

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

Расскажу, как я начал заниматься базой знаний. На заре моего трудоустройства коллега организовал мини-конкурс: автор наибольшего вклада в развитие вики должен был получить награду, достойную чемпиона стакан черной смородины (напомню, Veeam IT компания с достойными зарплатами, мы тут не голодаем). Смородина та кончилась пять-шесть лет назад, а проектом я занимаюсь и поныне. Не могу сказать, что это был гениальный ход с его стороны, но он сработал, а это главное.

Присматривайте за другими

У семи нянек детеныш без серебряной пули

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

Постмодерацией (патрулированием правок) нужно заниматься заниматься регулярно, в идеале каждый день. Да, это отнимает время, но это необходимо, чтобы вики не превращалась в помойку. Расставляйте категории, чините навигацию, исправляйте нестандартное форматирование, чистите текст от пассивно-агрессивных нападок и явных ошибок.

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

Вместо заключения или "насильно мил не будешь"

Лучше на гривну убытку, чем на алтын стыда

Ваша база знаний подойдет не для всего и не всем. Даже в моем случае MediaWiki самая популярная и большая внутренняя база знаний, но далеко не единственная. Есть команды, привыкшие на прошлых местах работы к Confluence/Sharepoint/впишите нужное. Отдельные команды все еще бойкотируют создание внутренней документации под теми или иными поводами. На мой взгляд, это нормально.

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

Пожелание "сделайте так, чтобы мою вики использовали, пожалуйста" мало чем отличается от "сделайте так, чтобы в мою игру играло много человек". Да, у продвижения разных сервисов и услуг есть свои особенности, но у них гораздо больше общего, чем может показаться. Чтобы продвигать базу знаний, попробуйте мыслить как SMM специалист и основатель стартапа в одном лице, а не как Пётр I, насильно сбривающий бороды (никаких претензий к Петру, просто подход другой). И хотя идеального способа продвижения нет и вероятно, никогда не появится, в ваших силах найти рабочие для вашей конкретной компании способы. Удачи!

В рунете я почти не встречал материалов о том, как писать расширения для MediaWIki (платформы, на которой работает Википедия). Основной стартовой точкой при написании расширений был и остается официальный сайт платформы, но там процесс расписан не очень дружелюбно по отношению к новичкам. Попробуем же это исправить.

В этой статье я покажу, как написать простейшее расширение для Медиавики, включающее в себя новый метод API, расширение парсера и немного js/css для фронтенда. А чтобы не было скучно, приплетем сюда работу с Google Knowledge Graph.

Расширения MediaWiki

MediaWiki модульная платформа, куда можно устанавливать расширения для добавления самого разного функционала. Помимо того, что расширения могут реализовывать какой-то свой независимый функционал (например, добавлять какие-нибудь виджеты), оно также может и модифицировать функциональность платформы: например, менять принцип работы поиска или модифицировать внешний вид платформы. Посмотреть примеры расширений можно на официальном сайте платформы.

Пишутся расширения, как правило, на php+jQuery. Возможность встраиваться в код ядра MediaWiki (или в код других расширений) реализована через т.н. хуки. Хуки позволяют вызывать дополнительный код по заданным событиям. Примерами таких событий могут быть: сохранение страницы, вызов поиска по сайту, открытие страницы на редактирование и так далее.

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

Что будем писать?

Готовое расширение можно взять тут:
https://github.com/Griboedow/GoogleKnowledgeGraph

Давайте развлечемся и напишем что-нибудь бесполезное. Скажем, расширение, которое будет вытаскивать описания с Google Knowledge Graph.

Т.е. расширение будет вот это:

Код этого приложения прост и изящен как <GoogleKnowledgeGraph query="Мэльхэнанвенанхытбельхын"/>

Превращать в это:

Штука довольно бесполезная, но она послужит хорошей иллюстрацией. Еще и с графом знаний Гугла поиграемся!

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

Как оно будет работать

Примерный принцип работы расширения выглядит так:

1. Пользователь сохраняет страницу, где в тексте присутствуют теги <GoogleKnowledgeGraph query="Ричард Докинз">.

   • MediaWIki позволяет использовать не только формат тега, но и формат функции парсера <link>: {{#GoogleKnowledgeGraph||query=Ричард Докинз}}.

2. Расширение функции парсера превращает тег в html код <span class="googleKnowledgeGraph">Ричард Докинз</span>

3. JS код при загрузке страницы идет по всем элементам .googleKnowledgeGraph и запрашивает через API нашего же расширения описания терминов, подставляя их в title.

4. API нашего расширения будет максимально примитивным: он будет передавать запросы от фронтенда на Google API, чистить ответ от всего лишнего и передавать очищенное описание сущности на фронт.

В целом, можно было бы обойтись и без фронтенда, но запросы на внешние сайты могут проходить не очень быстро. Лучше показать основной контент страницы пораньше, и в фоне догрузить необязательный контент. К тому же мы тут учимся, а не пишем серьезный код, верно?

Итого, нам потребуется:

1. Определить манифест нашего расширения.

2. Расширить MediaWIki API, добавив запрос на получение описания из Google Knowledge Graph

3. Расширить парсер MediaWiki, добавив обработку нового тега.

4. Добавить JS код, который будет выполняться по загрузке страницы

5. Подгрузить наше расширение в MediaWiki

6. Поделиться результатом наших трудов с сообществом.

А еще перед началом работы вам потребуется токен для работы с Google Knowledge Graph API. Сгенерировать его можно тут.

Создаем структуру расширения

Типичная иерархия файлов и папок для MediaWIki расширения выглядит так:

extensions                    <-- Папка всех расширений MediaWiki GoogleKnowledgeGraph      <-- Подпапка с нашим расширением      extension.json   <-- Манифест нашего расширения     i18n           <-- Каталог с используемыми строками для разных языков      en.json    <-- Строки на английском      qqq.json   <-- Описания строк для облегчения жизни переводчиков      ru.json    <-- Строки на русском     includes                             <-- PHP код      ApiGoogleKnowledgeGraph.php      <-- Расширение API      GoogleKnowledgeGraph.hooks.php   <-- Расширение парсера и другие хуки     modules                                <-- Папка с JS модулями          ext.GoogleKnowledgeGraph           <-- В нашем случае модуль только 1             ext.GoogleKnowledgeGraph.css   <-- CSS стили нашего модуля             ext.GoogleKnowledgeGraph.js    <-- JS код нашего модуля

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

Интернационализация (i18n)

Для того, чтобы нашим расширением было удобно пользоваться на всех языках, можно воспользоваться стандартной системой интернационализации banana-i18n. Помимо облегчения интернационализации, эта система также позволяет хранить все тексты в одном месте (а не раскиданными по коду). Выглядит это примерно так:

qqq.json

{"@metadata": {"authors": [ "Developer Name" ]},"googleknowledgegraph-description": "Description of the extension, to be show in Special:Vesion.","apihelp-askgoogleknowledgegraph-summary" : "Help string for 'askgoogleknowledgegraph' API request","apihelp-askgoogleknowledgegraph-param-query": "Help string for 'query' parameter of API request 'askgoogleknowledgegraph'"}

en.json

{"@metadata": {"authors": [ "Nikolai Kochkin" ]},"googleknowledgegraph-description": "The extension gets brief description from Google Knowledge Graph","apihelp-askgoogleknowledgegraph-summary" : "API to get description from Google Knowledge Graph","apihelp-askgoogleknowledgegraph-param-query": "String to ask from Google Knowledge Graph"}

Создаем манифест расширения (extension.json)

Для начала разберемся, как нам сообщить MediaWiki, что нужно загрузить то или иное расширение. Путей на самом деле два:

• Использоватьrequire_once( '/path/to/file.php' ). Этот метод считается устаревшим, так что мы его подробно не будем рассматривать.

• Использовать функцию wfLoadExtension('ExtensionName'). Сейчас этот способ считается основным, так что на нем и остановимся. http://personeltest.ru/aways/habr.com/ru/company/veeam/blog/544534

Второй способ подразумевает наличие в папке файла extension.json с описанием манифеста приложения (как оно называется, из чего состоит, какие хуки использует и так далее).

Определяем манифест (файл extension.json):

{"name": "GoogleKnowledgeGraph","version": "0.1.0","author": ["Nikolai Kochkin"],"url": "http://personeltest.ru/aways/habr.com/ru/company/veeam/blog/544534/","descriptionmsg": "googleknowledgegraph-description","license-name": "GPL-2.0-or-later","type": "parserhook","requires": {"MediaWiki": ">= 1.29.0"},"MessagesDirs": {"GoogleKnowledgeGraph": ["i18n"]},"AutoloadClasses": {"GoogleKnowledgeGraphHooks": "includes/GoogleKnowledgeGraph.hooks.php","ApiAskGoogleKnowledgeGraph": "includes/ApiAskGoogleKnowledgeGraph.php"},"APIModules": {"askgoogleknowledgegraph": "ApiAskGoogleKnowledgeGraph"},"Hooks": {"OutputPageParserOutput": "GoogleKnowledgeGraphHooks::onBeforeHtmlAddedToOutput","ParserFirstCallInit": "GoogleKnowledgeGraphHooks::onParserSetup"},"ResourceFileModulePaths": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules"},"ResourceModules": {"ext.GoogleKnowledgeGraph": {"localBasePath": "modules/ext.GoogleKnowledgeGraph","remoteExtPath": "GoogleKnowledgeGraph/modules/ext.GoogleKnowledgeGraph","scripts": ["ext.GoogleKnowledgeGraph.js"],"styles": ["ext.GoogleKnowledgeGraph.css"]}},"config": {"GoogleApiLanguage": {"value": "ru","path": false,"description": "In which language you want to get result from the Knowledge Graph","public": true},"GoogleApiToken": {"value": "","path": false,"description": "API token to be used with Google API","public": false}},"ConfigRegistry": {"GoogleKnowledgeGraph": "GlobalVarConfig::newInstance"},"manifest_version": 2}

Первая часть файла определяет то, что пользователь увидит в описании расширения на странице Special:Version

"name": "GoogleKnowledgeGraph","version": "0.1.0","author": ["Nikolai Kochkin"],"url": "http://personeltest.ru/aways/habr.com/ru/company/veeam/blog/544534/","descriptionmsg": "googleknowledgegraph-description","license-name": "GPL-2.0-or-later","type": "parserhook",

Далее мы указываем зависимости нашего расширения: с какими версиями MediaWIki расширение может работать, какие версии php требуются, какие расширения должны быть уже установлены и так далее.

"requires": {"MediaWiki": ">= 1.29.0"},

Затем мы указываем, где искать файлы со строками i18n

"MessagesDirs": {"GoogleKnowledgeGraph": ["i18n"]},

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

"AutoloadClasses": {"GoogleKnowledgeGraphHooks": "includes/GoogleKnowledgeGraph.hooks.php","ApiAskGoogleKnowledgeGraph": "includes/ApiAskGoogleKnowledgeGraph.php"},

Заявляем, что мы реализовываем API метод askgoogleknowledgegraph в классе ApiAskGoogleKnowledgeGraph

"APIModules": {"askgoogleknowledgegraph": "ApiAskGoogleKnowledgeGraph"},

Перечисляем, какие коллбеки для каких хуков у нас реализованы

"Hooks": {"BeforePageDisplay": "GoogleKnowledgeGraphHooks::onBeforePageDisplay","ParserFirstCallInit": "GoogleKnowledgeGraphHooks::onParserSetup"},

Сообщаем, что модули наши лежат в папке modules

"ResourceFileModulePaths": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules"},

И определяем наш фронтенд модуль с js и css. Когда модулей несколько, можно указать в коде зависимости между ними.

"ResourceModules": {"ext.GoogleKnowledgeGraph": {"localBasePath": "modules/ext.GoogleKnowledgeGraph","remoteExtPath": "GoogleKnowledgeGraph/modules/ext.GoogleKnowledgeGraph","scripts": ["ext.GoogleKnowledgeGraph.js"],"styles": ["ext.GoogleKnowledgeGraph.css"]}},

И, наконец, задаем дополнительные параметры конфигурации нашего расширения

"config": {"GoogleApiLanguage": {"value": "ru","path": false,"description": "In which language you want to get result from the Knowledge Graph","public": true},"GoogleApiToken": {"value": "","path": false,"description": "API token to be used with Google API","public": false}},"ConfigRegistry": {"GoogleKnowledgeGraph": "GlobalVarConfig::newInstance"},

В LocalSettings.php опции будут иметь стандартный префикс wg

$wgGoogleApiToken = 'your-google-token';$wgGoogleApiLanguage = 'ru';

И, наконец, задаем версию схемы манифеста

"manifest_version": 2

Мы используем лишь небольшой список поддерживаемых полей манифеста. Почитать обо всех полях можно тут.

Расширяем API

Для начала реализуем API.

В extension.json мы заявили, что у нас будет метод askgoogleknowledgegraph, реализованный в классе ApiAskGoogleKnowledgeGraph из файла includes/ApiAskGoogleKnowledgeGraph.php:

// extension.json fragment"AutoloadClasses": {    <...>    "ApiAskGoogleKnowledgeGraph": "includes/ApiAskGoogleKnowledgeGraph.php"},"APIModules": {           "askgoogleknowledgegraph": "ApiAskGoogleKnowledgeGraph"     },

Теперь реализуем наш метод. Файл includes/ApiAskGoogleKnowledgeGraph.php:

<?php/**  * Класс включает в себя реализацию и описание API метода askgoogleknowledgegraph * Для простоты я не реализую кеширование, любопытные могут подсмотреть реализацию тут:  * https://github.com/wikimedia/mediawiki-extensions-TextExtracts/blob/master/includes/ApiQueryExtracts.php */use MediaWiki\MediaWikiServices;class ApiAskGoogleKnowledgeGraph extends ApiBase {public function execute() {$params = $this->extractRequestParams();// query - обязательный параметр, так что $params['query'] всегда определен$description = ApiAskGoogleKnowledgeGraph::getGknDescription( $params['query'] );/** * Определяем результат для Get запроса.  * На самом деле Post запрос отработает с тем же успехом,  * если специально не отслеживать тип запроса \_()_/. */$this->getResult()->addValue( null, "description", $description );}/**  * Список поддерживаемых параметров метода */public function getAllowedParams() {return ['query' => [ApiBase::PARAM_TYPE => 'string',ApiBase::PARAM_REQUIRED => true,]];}/** * Получаем данные из Google Knowledge Graph,      * предполагая, что самый первый результат и есть верный. */private static function getGknDescription( $query ) {/** * Вытаскиваем параметры языка и токен. * Все параметры в LocalSettings.php имеют префикс wg, например: wgGoogleApiToken. * Здесь же мы их указываем без префикса */$config = MediaWikiServices::getInstance()->getConfigFactory()->makeConfig( 'GoogleKnowledgeGraph' );$gkgToken = $config->get( 'GoogleApiToken' );$gkgLang = $config->get( 'GoogleApiLanguage' );$service_url = 'https://kgsearch.googleapis.com/v1/entities:search';$params = ['query' => $query ,'limit' => 1,'languages' => $gkgLang,'indent' => TRUE,'key' => $gkgToken,];$url = $service_url . '?' . http_build_query( $params );$ch = curl_init();curl_setopt( $ch, CURLOPT_URL, $url) ;curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );$response = json_decode( curl_exec( $ch ), true );curl_close( $ch );if( count( $response['itemListElement'] ) == 0 ){return "Nothing found by your request \"$query\"";}if( !isset( $response['itemListElement'][0]['result'] ) ){return "Unknown GKG result format for request \"$query\"";}if( !isset($response['itemListElement'][0]['result']['detailedDescription'] ) ){return "detailedDescription was not provided by GKG for request \"$query\"";}if( !isset( $response['itemListElement'][0]['result']['detailedDescription']['articleBody'] ) ){return "articleBody was not provided by GKG for request \"$query\"";}return $response['itemListElement'][0]['result']['detailedDescription']['articleBody'];}}

Теперь мы можем обращаться по апи к нашей вики:

Get /api.php?action=askgoogleknowledgegraph&query=Выхухоль&format=jsonResponse body:{"description": "Выхухоль, или русская выхухоль, или хохуля,  вид млекопитающих отряда насекомоядных из трибы Desmanini подсемейства Talpinae семейства кротовых. Один из двух видов трибы; вторым видом является пиренейская выхухоль."}

Расширяем парсер и используем прочие хуки

// Фрагмент файла extension.json"AutoloadClasses": {"GoogleKnowledgeGraphHooks": "includes/GoogleKnowledgeGraph.hooks.php",<...>},"Hooks": {"BeforePageDisplay": "GoogleKnowledgeGraphHooks::onBeforePageDisplay","ParserFirstCallInit": "GoogleKnowledgeGraphHooks::onParserSetup"},

В extension.json мы заявили, что в классе GoogleKnowledgeGraphHooks из файла includes/GoogleKnowledgeGraph.hooks.php реализуем расширения для хуков:

• OutputPageParserOutput в методе onBeforeHtmlAddedToOutput;

• ParserFirstCallInit в методе onParserSetup

Немножко про используемые хуки:

• OutputPageParserOutput позволяет выполнить какой-то код после того, как парсер закончил формировать html, но перед тем, как html был добавлен к аутпуту. Здесь мы, например, можем подгрузить фронтенд. Фронтенд мы целиком расположили в модуле ext.GoogleKnowledgeGraph, так что достаточно будет подгрузить его.

• ParserFirstCallInit позволяет расширить парсер дополнительными методами. Мы добавим в парсер обработку тега <GoogleKnowledgeGraph>.

Итак, реализация (файл includes/GoogleKnowledgeGraph.hooks.php):

<?php/** * Хуки расширения GoogleKnowledgeGraph  */class GoogleKnowledgeGraphHooks {/** * Сработает хук после окончания работы парсера, но перед выводом html.  * Детали тут: https://www.mediawiki.org/wiki/Manual:Hooks/OutputPageParserOutput */public static function onBeforeHtmlAddedToOutput( OutputPage &$out, ParserOutput $parserOutput ) {// Добавляем подгрузку модуля фронтенда для всех страниц, его определение ищи в extension.json$out->addModules( 'ext.GoogleKnowledgeGraph' );return true;}/** * Расширяем парсер, добавляя обработку тега <GoogleKnowledgeGraphHooks> */public static function onParserSetup( Parser $parser ) {$parser->setHook( 'GoogleKnowledgeGraph', 'GoogleKnowledgeGraphHooks::processGoogleKnowledgeGraphTag' );return true;}/** * Реализация обработки тега <GoogleKnowledgeGraph>  */public static function processGoogleKnowledgeGraphTag( $input, array $args, Parser $parser, PPFrame $frame ) {// Парсим аргументы, переданные в формате <GoogleKnowledgeGraph arg1="val1" arg2="val2" ...> if( isset( $args['query'] ) ){$query = $args['query'];}else{// В тег не был передан аргумент query, так что и выводить нам нечегоreturn '';}return '<span class="googleKnowledgeGraph">' . htmlspecialchars( $query ) . '</span>';}}

Добавляем фронтенд

Фронтенд свяжет воедино все, что мы реализовали выше.

// Фрагмент файла extension.json    "ResourceModules": {"ext.GoogleKnowledgeGraph": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules","scripts": ["ext.GoogleKnowledgeGraph.js"],"styles": ["ext.GoogleKnowledgeGraph.css"],"dependencies": []}},  "ResourceFileModulePaths": {"localBasePath": "modules","remoteExtPath": "GoogleKnowledgeGraph/modules"},

В extension.json мы заявили, что у нас есть один модуль ext.GoogleKnowledgeGraph, который находится в папке modules и состоит из двух файлов:

• modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.js

• modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.css

Загрузку модуля мы реализовали чуть раньше в методе onBeforeHtmlAddedToOutput. Определим теперь и сам код модуля.

Для начала зададим стили
(файл modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.css):

.googleKnowledgeGraph{    border-bottom: 1px dotted #000;    text-decoration: none;}

А теперь возьмемся за JS
(файл modules/ext.GoogleKnowledgeGraph/ext.GoogleKnowledgeGraph.js):

( function ( mw, $ ) {  /**   * Ищем все элементы с <span class="googleKnowledgeGraph">MyText</span>,   * вытаскиваем MyText и отправляем запрос   * /api.php?action=askgoogleknowledgegraph&query=MyText   * После чего добавляем результат в 'title'.   */$( ".googleKnowledgeGraph" ).each( function( index, element ) {$.ajax({type: "GET", url: mw.util.wikiScript( 'api' ),data: { action: 'askgoogleknowledgegraph', query: $( element ).text(),format: 'json',},dataType: 'json',success: function( jsondata ){$( element ).prop( 'title', jsondata.description );}});});}( mediaWiki, jQuery ) );

JS код довольно прост. jQuery нам достался даром, поскольку MediaWiki подгружает его автоматически.

Подгружаем наше расширение и радуемся

Для загрузки расширения, как мы уже обсуждали, потребуется поправить файл LocalSettings.php. Добавляем в самый конец:

// Фрагмент файла LocalSettings.php<?php<...>  wfLoadExtension( 'GoogleKnowledgeGraph' );$wgGoogleApiToken = "your-google-token";$wgGoogleApiLanguage = 'ru';

Можно пробовать! Добавим на страницу что-нибудь эдакое:

Даже <GoogleKnowledgeGraph query="прикольный флот"/> может стать отстойным.

И получим:

Делимся с сообществом

Если есть возможность поделиться расширением с общественностью, то можно создать страницу на MediaWiki с кратким описанием, что ваше расширение может сделать (не забудьте скриншоты: лучше один раз увидеть, чем сто раз прочитать). На страницы с описаниями расширений обычно добавляют шаблон Extension, поля которого хорошо задокументированы. Если же возникнут сложности, всегда можно скопировать его с другой страницы расширений и подправить отличающиеся поля.

Заключение

В статье был описан случай довольно простого расширения, но, на самом деле, такие расширения как iFrame, CategoryTree, Drawio и многие другие не очень далеко ушли по сложности.

За скобками остались такие вещи, как работа с базой, кэширование, OOUI и много-многое другое. Все ж я вас не напугать хотел, а как раз наоборот показать, что писать расширения под вики на самом деле совсем не сложно и не страшно.

Ссылки

• Код расширения целиком на github

• Страница расширения на MediaWiki

• Страница помощи разработчику расширений MediaWIki

• Example extension расширение с пачкой примеров на все случаи жизни

• Документация MediaWiki кода

• banana-i18n (как работает интернационализация)

• Схема extension.json (файл поддерживает много дополнительных полей)

Скажите честно, в своей практике вам чаще приходилось сталкиваться с логами, напоминающими чей-то поток сознания, или всё же это были красивые структурированные файлы, на которые любо-дорого смотреть? Надеюсь, что второе. В наших продуктах, само собой, мы тоже стремимся идти по второму пути, однако необходимость зафиксировать большое количество процессов накладывает свой отпечаток. Так что сегодня мы научимся не читать книгу и видеть фигу, а бесстрашно открывать любой лог Veeam Backup & Replication и видеть его внутреннюю красоту.

Перед прочтением этой статьи настоятельно рекомендую предварительно ознакомиться со статьёй-глоссарием, дабы понимать используемую терминологию. Затем прочитать эту статью про источники данных для логов. А затем ещё и эту, дабы понимать, в какой лог ради чего следует залезать.

Когда читаешь логи, очень важно держать в голове и применять шесть простых правил.

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

// Виму надо отключиться от vCenter:[19.10.2020 05:02:53] <01> Info [Soap] Logout from "https://vcenter.test.local:443/sdk"// Убеждаемся, что мы действительно отключились, попробовав выполнить любое действие. Получить ошибку здесь  ожидаемый результат.[19.10.2020 05:02:53] <01> ErrorThe session is not authenticated. (System.Web.Services.Protocols.SoapException)[19.10.2020 05:02:53] <01> Error at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)

Правило второе: Когда читаете лог, не надо смотреть только на последнюю в списке ошибку. Даже если она подсвечена в репорте, упавшем на почту. Причина её появления запросто может быть на пару экранов (и десяток других ошибок) выше. Например, в упавшем на почту HTML репорте видим ошибку "Microsoft SQL server hosting the configuration database is currently unavailable". Открываем лог джобы и видим, что последняя ошибка в логе прямо нам говорит Не могу подключиться к SQL серверу, потому что <причины>.

[12.11.2019 23:24:00] <18> Error Microsoft SQL server hosting the configuration database is currently unavailable. Possible reasons are heavy load, networking issue, server reboot, or hot backup.[12.11.2019 23:24:00] <18> Error Please wait, and try again later.

Сразу хочется победно прокричать Ага! и побежать чинить связь до SQL сервера, перезагружать его, трясти за бампер и пинать по колесу. Однако если попробовать разобраться и отмотать лог ближе к началу, там обнаруживаются строки:

12.11.2019 23:22:00] <18> Error Violation of PRIMARY KEY constraint 'PK_Storages'. Cannot insert duplicate key in object 'dbo.Backup.Model.Storages'. The duplicate key value is (af4d30aa-9605-4fe6-8229-f362eb848f19).[12.11.2019 23:22:00] <18> Error Violation of PRIMARY KEY constraint 'PK_Storages'. Cannot insert duplicate key in object 'dbo.Backup.Model.Storages'. The duplicate key value is (af4d30aa-9605-4fe6-8229-f362eb848f19).

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

Правило третье: Редкая ошибка локализуется внутри одного конкретного лога. Изучение соседних логов на тот же момент времени позволяет собрать намного больше информации. Хрестоматийный пример это лог джобы, где нам просто говорят, что возникала такая-то ошибка в такой-то таске. Какие-то выводы, конечно, мы сделать уже можем, но лучше открыть лог таски и получить более подробное описание случившегося бедствия. И если уж совсем ничего не понятно, то нам на помощь приходят логи агентов, в которых вся ситуация будет разобрана крайне подробно. Но тут действует правило Чем дальше в лес, тем более узким и специфичным становится лог. А ещё часть инфы может всплыть в сервисных логах, часть в виндовых ивентах и так далее.

Вот, например, берём типичный лог упавшей джобы:

[13.06.2019 11:06:07] <52> Error  Failed to call RPC function 'CreateSessionTicket': Agent with the specified identifier '{c8fdc9b9-0d60-486c-80de-9fc4218d276f}' does not exist

Типичный никчёмный Failed to call RPC function, из которого максимум, что можно понять что не удалось провзаимодействовать с транспортным агентом. Однако если вспомнить, что транспортный агент управляется транспортным сервисом (известен в документации как Datamover) и заглянуть в его лог (Svc.VeeamTransport.log) на хосте, где он запускался, то можно обнаружить:

[13.06.2019 09:05:07] < 10648> tpl|   Agent '{c8fdc9b9-0d60-486c-80de-9fc4218d276f}' will be terminated due to reason: some I/O operation has hanged.[13.06.2019 09:06:07] < 10648> tpl| WARN|AGENT [{c8fdc9b9-0d60-486c-80de-9fc4218d276f}] HAS HANGED UNEXPECTEDLY AND WAS TERMINATED.

То есть агент был принудительно выключен сервисом после неудачной попытки записать что-то на таргет, но к VBR эта информация по какой-то причине не пришла. Теперь мы хотя бы знаем, в какую сторону копать.

Правило четвёртое: Если в логах видим, что ошибка происходит где-то за границами компонентов VBR, значит, искать их причину надо тоже за границами компонентов VBR. Veeam хоть и старательно логирует все приходящие к нему события, однако ещё больше их(событий) остаётся на целевой системе. Типичным примером здесь будет создание VSS снапшота. По большому счёту, Windows отдаёт информацию на уровне получилось или нет что-то сделать, из чего крайне редко получается вычленить причину, почему же не получилось. Однако внутри виндовых ивентов можно найти множество событий, прямо указывающих на проблему. Главное всегда тщательно сопоставлять время в логах от разных систем. Помним, что у VBR своё время, у vSphere всегда UTC+0, а виндовые ивенты показываются в локальном времени машины, на которой их смотрят. Типичные примеры экспорта внешних логов для Windows и для Microsoft SQL.

Правило пятое: Следи за тредами (они обозначаются как <XX>) и распутывай клубок последовательно! Многие вещи могут происходить параллельно, и если просто читать логи линия за линией, то можно прийти к неправильному выводу. Особенно это важно, если джоба кажется зависшей и надо понять, что именно в ней зависло.

Вот типичный лог для этой ситуации:

[18.06.2020 03:44:03] <36> Info [AP] Waiting for completion. Id: [0xf48cca], Time: 00:30:00.0333386[18.06.2020 03:45:18] <53> Info [AP] (6ff9) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.

Если читать это лог, не обращая внимания на номера тредов <36> и <53>, то кажется, что у нас какие-то проблемы с агентом 6ff9, и надо срочно разбираться, что с ним случилось. Однако если продолжить чтение лога с оглядкой на тред <36>, то обнаруживается, что:

[18.06.2020 03:14:03] <36> Info  [AP] (bf19) command: 'Invoke: DataTransfer.SyncDisk

То есть этот тред посвящён совершенно другому агенту с id bf19! Открываем лог этого агента и видим:

[17.06.2020 12:41:23] <  2160>  ERR |Data error (cyclic redundancy check).[17.06.2020 12:41:23] <  2160>  >>  |Failed to read data from the file [E:\Hyper-V\VHDs\SRV-DCFS02\SRV-DCFS02-C.vhdx].

Значит, проблема в битом VHDX и надо искать методы его лечения.

Правило шестое: Не получается, непонятно, кажется, что вот-вот, но идёт третий день без сна и всё никак звони в сапорт! Veeam огромный продукт, где есть тысячи нюансов, нюансы для нюансов и прочих сокровенных знаний, которые никогда не понадобятся 99,99% населения этой планеты. Однако именно этих знаний в большинстве случаев и не хватает, чтобы успешно найти причину неисправности самому. Сапорт Вима совсем не просто так получает свою зарплату и считается одним из лучших в IT-индустрии. А ещё он русскоязычный и доступен по телефону ;)

Смело открываем лог

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

===================================================================Starting new logLog has been started by 'VEEAM\SYSTEM' user (Non-interactive)Logging level: [4 (AboveNormal)]MachineName: [VEEAM], OS: [Microsoft Windows Server 2019 Standard (10.0.17763)], CPU: [2]Process: [64 bit], PID: [10816], SessionId: [0]UTC Time: [22.10.2020 2:03:53], DaylightSavingTime: [False]Culture: [ru-RU], UI culture: [en-US]Module: [C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Manager.exe]. File version: [10.0.1.4854], Assembly version: [10.0.0.0], Edition: [standard]Process start time: [22.10.2020 0:01:19], Garbage collector mode: [Workstation]CmdLineParams: [startbackupjob owner=[vbsvc] Normal bed49ecd-54a4-4f53-b337-e71fabe92988 44c3f481-66ec-475f-bd04-a321e69274a0]Network Interface, Name: Ethernet0, Description: Intel(R) 82574L Gigabit Network Connection, Interface Type: Ethernet, Operational Status: Up;Unicast IPAddresses: fe80::b99c:9c8a:6179:295b%6; 172.17.32.51;Gateway IPAddresses: 172.17.32.1;Network Interface, Name: Loopback Pseudo-Interface 1, Description: Software Loopback Interface 1, Interface Type: Loopback, Operational Status: Up;Unicast IPAddresses: ::1; 127.0.0.1;UTC offset: 3,00 hours

Начало не вызывает никаких особых вопросов. Мы видим, как называется машина, на которой установлен VBR, и под каким пользователем запускается Veeam Backup Service.

Log has been started by 'VEEAM\SYSTEM' user (Non-interactive)MachineName: [VEEAM], OS: [Microsoft Windows Server 2019 Standard (10.0.17763)],

Важный пункт это версия запускающегося модуля.

Module: [C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Manager.exe]. File version: [10.0.1.4854], Assembly version: [10.0.0.0], Edition: [standard]

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

Затем идёт перечисление всех сетевых интерфейсов и их IP-адреса. Также по названию карты зачастую можно понять, стоит ли Veeam на виртуальной машине или на физической. Хотя вы и сами наверняка это знаете, но может пригодиться.

Network Interface, Name: Ethernet0, Description: Intel(R) 82574L Gigabit Network Connection, Interface Type: Ethernet, Operational Status: Up;Unicast IPAddresses: fe80::b99c:9c8a:6179:295b%6; 172.17.32.51;Gateway IPAddresses: 172.17.32.1;Network Interface, Name: Loopback Pseudo-Interface 1, Description: Software Loopback Interface 1, Interface Type: Loopback, Operational Status: Up;Unicast IPAddresses: ::1; 127.0.0.1;

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

UTC Time: [22.10.2020 2:03:53], DaylightSavingTime: [False]UTC offset: 3,00 hours

Теперь, когда заголовок прочитан, давайте на примере бекапа и реплики посмотрим, что нас ожидает в логе любой джобы. Я не буду объяснять каждую строчку, иначе мы отсюда через месяц только разойдёмся. Просто легкая пробежка по общему принципу.

• Первым делом джоба должна перечитать свои собственные настройки, дабы вообще знать, что ей требуется сделать.

• Затем формируется список объектов, участвующих в бекапе.

• Для всех объектов надо заблокировать необходимые ресурсы (файлы с бекапами, например) и убедиться, что никто другой не пытается с ними работать в этот момент времени.

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

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

• И в конце, когда все таски отчитались, наступает тяжелая пора проверки ретеншенов. Удаляются старые точки, запускаются синтетические трансформы и прочий страшный сон для ваших СХД.

• Когда всё закончилось успехом, надо везде рапортовать про это, записать в базу новую информацию и счастливо заснуть до следующего запуска. Конечно, строго говоря, на фоне будет происходить масса разнообразных и увлекательных сервисных вещей, но сегодня не об этом.

Теперь давайте обратим внимание на таски. Каждая таска запускается с чётко поставленной целью забекапить конкретную машину. Значит, после запуска её дело это суметь подключиться к хосту, запустить агентов (в документации известны как data movers), проверить, что есть связь между компонентами, и совершить процесс передачи информации от хранилища вашего хоста до бекапного репозитория с необходимыми трансформациями по пути. Сжатие, разжатие, дедупликация, шифрование и так далее.

Соответственно, начинаем поиски проблемы широкими мазками, а именно выясняем, на каком моменте всё сломалось. В этом нам помогает волшебное словосочетание has been completed. В общем случае таски рапортуют таким образом:

[19.10.2020 05:02:44] <29> Info Task session [3af0e723-b2a3-4054-b4e3-eea364041402] has been completed, status: Success, 107,374,182,400 of 107,374,182,400 bytes, 55,326,015,488 of 55,326,015,488 used bytes, 14 of 14 objects, details:

14 объектов это так называемые OiB, Object in Backup. Эта информация дублируется в логе джобы после завершения каждой таски с пометкой о том, сколько тасок уже завершилось. А в самом конце джоба должна заканчиваться полным отчётом.

[19.10.2020 05:02:53] <01> Info Job session '0f8ad58b-4183-4500-9e49-cc94f0674d87' has been completed, status: 'Success', '100 GB' of '100 GB' bytes, '1' of '1' tasks, '1' successful, '0' failed, details: '', PointId: [d3e21f72-9a52-4dc9-bcbe-98d38498a3e8]

Другая полезная фраза это Preparing point. Позволяет нам понять, какой тип бекапа сейчас будет создаваться.

В случае создания полного бекапа, в народе именуемого фульник (Full или Active full), создаётся следующая запись:

[17.11.2019 22:01:28] <01> Info Preparing point in full mode 

Инкрементальный проход выглядит вот так:

[17.11.2019 22:01:28] <01> Info Preparing point in incremental mode 

И реверс инкремент:

[17.11.2019 22:01:28] <01> Info Preparing point in synthetic mode 

Для Synthetic full своей особой записи не существует! Она начинает с создания обычного инкремента, поэтому надо искать ниже в логе запись "Creating synthetic full backup". Или пройтись по "Preparing oib" в логе таски.

vSphere

Теперь переходим к специфике гипервизоров, ибо, как можно легко догадаться, VMware и Hyper-V под капотом устроены даже приблизительно не одинаково, так что и работать с ними надо по-разному.

И начнём мы именно с VMware. Для начала просто посмотрим версию хоста по слову Build- в логе джобы. Так мы сможем узнать версию и номер билда хоста с машиной. Если хост был добавлен как часть Vcenter, бонусом получаем поле source host type.

[01.11.2020 05:00:26] <01> Info VM task VM name: 'vudc01', VM host name: 'https://esxi.test.local', VM host info: 'VMware ESXi 6.5.0 build-16207673', VM host apiVersion: '6.5', source host name: 'vcenter.test.local', source host id: '3de6c11c-ad7e-4ec0-ba12-d99a0b30b493', source host type: 'VC', size: '107374182400', display name: 'vudc01'.

Эта же информация дублируется в момент проверки доступных режимов работы прокси.

[01.11.2020 05:00:24] <01> Info [ProxyDetector] Proxy [dsg.test.local] lies in different subnet with host [VMware ESXi 6.5.0 build-16207673]

В логе соответствующей таски это всё тоже имеется, только там это часть здоровенной XML, так что копипастить я её не буду. Зато там есть даже более интересная строка Host content info:

[01.11.2020 05:01:37] <37> Info  [Soap] Host content info: host "vcenter.test.local", type "vpx", version "6.5.0", build "15259038", apiVersion "6.5", hostTime "01.11.2020 2:01:26", sessionKey: "52c2dbf9-1835-2eb3-bb0e-396166a8101f"

Там же, в логе таски, можно получить информацию о дисках и датасторах по строке Disk: label

[07.08.2019 06:55:41] <82> Info Disk: label "Hard disk 1", path "[ALLIN_PURE_GDI] LXRP-IT-GPILDB1/LXRP-IT-GPILDB1_21.vmdk", capacity 25,0 GB, backing "CFlatVirtualDiskV2", mode "persistent", thinProvisioned "False"

Как мы видим, нас интересует ALLIN_PURE_GDI, поэтому переключаемся на лог джобы и видим:

[12.08.2019 05:40:12] <01> Info [ProxyDetector] Datastore 'ALLIN_PURE_GDI' lun was found, it uses vmfs

или

[12.08.2019 05:40:12] <01> Info [ProxyDetector] Datastore 'ALLIN_PURE_GDI' lun was found, it uses nas

Ещё бывает "Backup VM 'VMname' is DirectNFS compatible", но это не значит, что наша машина точно на NFS шаре.

Жизненный цикл vSpehere снапшотов

и места, где они обитают.

Часто (а на самом деле практически всегда) понимать, в какой момент создавался снапшот, в какой был удалён и что с ним происходило, весьма важно для получения целостной картины мира реплик и бекапов. Поэтому открываем лог таски и ищем в нём API вызовы для создания и консолидации (удаления) снапшотов. Создание снапшота отлично ищется по Create snapshot

[02.11.2020 05:01:09] <29> Info [VimApi] Create snapshot, ref "vm-26", name "VEEAM BACKUP TEMPORARY SNAPSHOT", description "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False"[02.11.2020 05:01:11] <29> Info [Soap] Snapshot VM 'vm-26' was created. Ref: 'snapshot-540'

Удаление снапшота ищется по Removing snapshot.

[01.11.2020 05:02:30] <26> Info [Soap] Removing snapshot 'snapshot-536'[01.11.2020 05:02:30] <26> Info [VimApi] RemoveSnapshot, type "VirtualMachineSnapshot", ref "snapshot-536", removeChildren "False"[01.11.2020 05:02:32] <26> Info [VmSnapshotTracker] Snapshot id: 'snapshot-536' closed[01.11.2020 05:02:32] <26> Info [Soap] Loaded 2 elements[01.11.2020 05:02:32] <26> Info [ViSnapshot] Checking if disks consolidation is needed for vm 'vm-26'[01.11.2020 05:02:32] <26> Info [ViSnapshot] Consolidation is not needed

Здесь что хочется отметить: по загадочной причине в логе VMware.log зачастую нет никакой информации об ошибках произошедших во время создания/удаления снапшота. Поэтому полную картину мира надо восстанавливать по всем логам vSphere, включая логи VPXD и HOSTD.

С точки зрения vSphere, в VMware.log обычно есть только события на создание снапшота:

2019-05-24T13:58:57.921Z| vmx| I125: SnapshotVMX_TakeSnapshot start: 'VEEAM BACKUP TEMPORARY SNAPSHOT', deviceState=0, lazy=0, quiesced=0, forceNative=0, tryNative=1, saveAllocMaps=0 cb=35DE089A0, cbData=35F700420 ....2019-05-24T13:59:01.111Z| vcpu-0| I125: VigorTransport_ServerSendResponse opID=a9e2725d-8d3e-41c3-bea7-40d55d4d13fe-3088830-h5c:70160745-a8-af-3321 seq=187319: Completed Snapshot request. 

И на удаление:

2019-05-24T13:59:31.878Z| vmx| I125: SNAPSHOT: SnapshotDeleteWork '/vmfs/volumes/5b0c32e4-3bc067bb-614b-f4e9d4a8b220/test_build/test_build.vmx' : 29....2019-05-24T13:59:35.411Z| vcpu-0| I125: ConsolidateEnd: Snapshot consolidate complete: The operation completed successfully (0).

Причём снапшоты, сделанные вручную, логируются несколько иначе, но это детали.

Зато как только мы заводим разговор о репликах, всё становится ещё веселее. VMware.log ведётся только когда виртуалка работает. А для реплицированных машин нормальное состояние быть выключенными. Так что этот лог вам никак помочь не может. Поэтому здесь нам понадобятся логи vCenter или хоста. Самый простой способ их добыть это ПКМ на vCenter > Export System Logs. В открывшемся визарде обязательно выбираем "Include vCenter server logs" и дожидаемся скачивания результата. Логи влёгкую могут весить несколько гигабайт, а скачиваться будут через браузер. Так что советую делать это на машине максимально близкой к VC. Самое интересное для нас внутри, это:

• ESXi: В архиве проходим по /var/run/log/ и находим hotsd.log. Рядом будут лежать упакованные более ранние версии.

• VC: ищем файлы vpxd-xxx.log по пути /var/log/vmware/vpxd.

Теперь давайте сравним, как будут выглядеть записи об одних и тех же операция в логе VBR, логе vpxd, и логе hostd. Здесь мы опустим моменты создания снапшота на исходной машине, так как нас интересует только реплика.

Итак, поскольку последний дельта-файл реплики доступен для записи и мы не можем гарантировать, что там никто ничего не натворил (горячий привет всем любящим включать реплицированные машины прямо с хоста), первым делом мы должны откатить все эти изменения:

//Veeam Task log:[19.05.2020 18:41:04] <20> Info [SnapReplicaVm] Find working snapshots for replica vm '[name 'TinyLinux2_replica', ref 'vm-3411']'[19.05.2020 18:41:04] <20> Info [SnapReplicaVm] Reverting vm '[name 'TinyLinux2_replica', ref 'vm-3411']' to restore point '5/19/2020 15:37:13'[19.05.2020 18:41:04] <20> Info [Soap] Reverting snapshot snapshot-3415[19.05.2020 18:41:04] <20> Info [VimApi] RevertSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3415"

//VPXD:2020-05-19T15:41:00.508Z info vpxd[04767] [Originator@6876 sub=vpxLro opID=7717265a] [VpxLRO] -- BEGIN task-32169 -- snapshot-3415 -- vim.vm.Snapshot.revert -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)

//Hostd:2020-05-19T15:41:00.492Z info hostd[2099911] [Originator@6876 sub=Vimsvc.TaskManager opID=7717265a-a1-62d8 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.vm.Snapshot.revert-53704072020-05-19T15:41:00.652Z info hostd[2099895] [Originator@6876 sub=Vimsvc.TaskManager opID=7717265a-a1-62d8 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Completed : haTask-676-vim.vm.Snapshot.revert-5370407 Status success

После успешного отката (двусмысленные фразы, что вы делаете, аха-ха-ха, прекратите) нам надо зафиксировать успех, т.е. сделать текущую дельту доступной только для чтения. Для этого создаём ещё один снапшот сверху:

//Veeam Task log:[19.05.2020 18:41:17] <20> Info [SnapReplicaVmTarget] Creating working snapshot[19.05.2020 18:41:17] <20> Info [SnapReplicaVm] Creating working snapshot for replica vm '[name 'TinyLinux2_replica', ref 'vm-3411']'[19.05.2020 18:41:19] <20> Info [VimApi] Create snapshot, ref "vm-3411", name "Veeam Replica Working Snapshot", description "<RPData PointTime="5249033617402408751" WorkingSnapshotTime="5249033617402408751" PointSize="0" PointType="EWorkingSnapshot" DescriptorType="Default" />", memory "False", quiesce "False"[19.05.2020 18:41:21] <20> Info [Soap] Snapshot VM 'vm-3411' was created. Ref: 'snapshot-3416'

//VPXD:2020-05-19T15:41:15.469Z info vpxd[00941] [Originator@6876 sub=vpxLro opID=32de210d] [VpxLRO] -- BEGIN task-32174 -- vm-3411 -- vim.VirtualMachine.createSnapshot -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)

//Hostd:2020-05-19T15:41:15.453Z info hostd[2099906] [Originator@6876 sub=Vimsvc.TaskManager opID=32de210d-b7-635b user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.VirtualMachine.createSnapshot-53704362020-05-19T15:41:15.664Z info hostd[2099914] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.VirtualMachine.createSnapshot-5370436 Status success

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

//Veeam Task log:[19.05.2020 18:41:44] <20> Info [Soap] Reverting snapshot snapshot-3416[19.05.2020 18:41:44] <20> Info [VimApi] RevertSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3416"[19.05.2020 18:41:46] <20> Info [Soap] Removing snapshot 'snapshot-3416'[19.05.2020 18:41:46] <20> Info [VimApi] RemoveSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3416", removeChildren "False

//VPXD:2020-05-19T15:41:40.571Z info vpxd[22153] [Originator@6876 sub=vpxLro opID=15fb90d9] [VpxLRO] -- BEGIN task-32176 -- snapshot-3416 -- vim.vm.Snapshot.revert -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)2020-05-19T15:41:42.758Z info vpxd[17341] [Originator@6876 sub=vpxLro opID=1b7624e9] [VpxLRO] -- BEGIN task-32177 -- snapshot-3416 -- vim.vm.Snapshot.remove -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)

//Hostd:2020-05-19T15:41:40.966Z info hostd[2099914] [Originator@6876 sub=Vimsvc.TaskManager opID=15fb90d9-ad-6417 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Completed : haTask-676-vim.vm.Snapshot.revert-5370516 Status success2020-05-19T15:41:42.764Z info hostd[6710321] [Originator@6876 sub=Vimsvc.TaskManager opID=1b7624e9-89-6435 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.vm.Snapshot.remove-53705222020-05-19T15:41:42.995Z info hostd[2099912] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.vm.Snapshot.remove-5370522 Status success

Но поскольку свято место пусто не бывает, сразу после удаления этого снапшота надо создать новый, который возьмёт на себя ответственность называться Restore Point. Хотя фактически он служит той же цели запрещает изменять предыдущую дельту, где лежат данные с боевой машины.

//Veeam Task log:[19.05.2020 18:41:51] <20> Info [VimApi] Create snapshot, ref "vm-3411", name "Restore Point 5-19-2020 18:40:53", description "<RPData PointTime="5248941014961933064" WorkingSnapshotTime="5249033617402408751" PointSize="64" PointType="ECompleteRestorePoint" DescriptorType="Default" />", memory "False", quiesce "False"[19.05.2020 18:41:53] <20> Info [Soap] Snapshot VM 'vm-3411' was created. Ref: 'snapshot-3417'

//VPXD:2020-05-19T15:41:47.170Z info vpxd[48063] [Originator@6876 sub=vpxLro opID=5cc1af26] [VpxLRO] -- BEGIN task-32179 -- vm-3411 -- vim.VirtualMachine.createSnapshot -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)

//Hostd:2020-05-19T15:41:47.155Z info hostd[2099311] [Originator@6876 sub=Vimsvc.TaskManager opID=5cc1af26-f3-646c user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.VirtualMachine.createSnapshot-53705392020-05-19T15:41:47.303Z info hostd[2099419] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.VirtualMachine.createSnapshot-5370539 Status success

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

//Veeam Job Log:[19.05.2020 18:42:21] <49> Info [SnapReplicaVm] DeleteRestorePoint 'PointTime: 5/19/2020 15:33:10, DigestStorageTimeStamp: 9/3/2020 19:51:05, SnapshotRef: snapshot-3413, Type: Default'[19.05.2020 18:42:21] <49> Info [Soap] Removing snapshot 'snapshot-3413'[19.05.2020 18:42:21] <49> Info [VimApi] RemoveSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3413", removeChildren "False"

//VPXD:2020-05-19T15:42:17.312Z info vpxd[49540] [Originator@6876 sub=vpxLro opID=7e40daff] [VpxLRO] -- BEGIN task-32181 -- snapshot-3413 -- vim.vm.Snapshot.remove -- 528b44cf-9794-1f2d-e3ff-e3e78efc8f76(52b14d11-1813-4647-353f-cfdcfbc6c149)

//Hostd:2020-05-19T15:42:17.535Z info hostd[2099313] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.vm.Snapshot.remove-5370588 Status success2020-05-19T15:42:17.302Z info hostd[6710322] [Originator@6876 sub=Vimsvc.TaskManager opID=7e40daff-e0-6513 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.vm.Snapshot.remove-5370588

Ищем компоненты

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

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

И да, это будет опять vSphere. Получить общую информацию проще всего в логе таски по строке Processing object

[02.11.2020 05:00:38] <29> Info Processing object 'vudc01' ('vm-26') from host 'vcenter.test.local' ('3de6c11c-ad7e-4ec0-ba12-d99a0b30b493')

Чуть ниже уже будет более подробная информация в строке VM information. Как видим, для машин, добавленных через VC, указывается, в том числе, и хост.

[01.11.2020 05:00:46] <26> Info VM information: name "vudc01", ref "vm-26", uuid "564d7c38-f4ae-5702-c3c9-6f42ef95535c", host "esx02.test.local", resourcePool "resgroup-22", connectionState "Connected", powerState "PoweredOn", template "False", changeTracking "True", configVersion "vmx-08"

Далее следует масса информации про выбор прокси и доступных режимов работы. Всё это происходит под тегом [ProxyDetector]. Общий алгоритм таков: берём и проверяем возможность скачать диски поочередно в режимах SAN > HotAdd > NBD. Каким способом получилось, так и качаем. Начинается всё веселье в этом моменте:

[01.11.2020 05:00:24] <01> Info [ProxyDetector] Trying to detect source proxy modes for VM [vudc01], has snapshots:False, disk types:[Scsi: True, Sata: False, Ide: False, Nvme: False][01.11.2020 05:00:24] <01> Info [ProxyDetector] Host storage 'VMware ESXi 6.5.0 build-16207673' has 1 luns

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

[16.09.2020 00:08:01] <01> Info [ProxyDetector] Trying to detect source proxy modes for VM [TinyLinux2], has snapshots:False, disk types:[Scsi: True, Sata: False, Ide: False, Nvme: False][16.09.2020 00:08:11] <01> Info [ProxyDetector] Detecting storage access level for proxy [VMware Backup Proxy][16.09.2020 00:08:11] <01> Info Proxy [VMware Backup Proxy] - is in the same subnet as host [VMware ESXi 6.7.0 build-16[16.09.2020 00:08:11] <01> Info [ProxyDetector] Detected mode [nbd] for proxy [VMware Backup Proxy]...[16.09.2020 00:08:13] <01> Info [ProxyDetector] Trying to detect target proxy modes, sanAllowed:False, vmHasSnapshots:True, diskTypes:[Scsi: True, Sata: False, Ide: False, Nvme: False], vmHasDisksWithoutUuid:False[16.09.2020 00:08:24] <01> Info [ProxyDetector] Detecting storage access level for proxy [10.1.10.6][16.09.2020 00:08:24] <01> Info [ProxyDetector] Detected mode [nbd] for proxy [10.1.10.6]

Какой прокси, в каком режиме и куда был назначен надо смотреть в логе каждой таски по фразе Preparing for processing of disk

[16.09.2020 01:03:28] <20> Info Preparing for processing of disk [shared-spbsupstg02-ds04] TinyLinux2/TinyLinux2.vmdk, resources: source proxy 'VMware Backup Proxy' and target proxy '10.1.10.6'[16.09.2020 01:03:28] <34> Info Processing disk '[shared-spbsupstg02-ds04] TinyLinux2/TinyLinux2.vmdk'[16.09.2020 01:03:28] <34> Info Using source proxy 'VMware Backup Proxy' and target proxy '10.1.10.6' for disk processing

Также полезное можно найти в логе /Utils/VMC.log. С ним только одна сложность: вся информация внутри представлена в виде ID. Никаких имён и человекочитаемых названий. Слава роботам!

[16.09.2020 04:05:40] <56> Info [ViProxyEnvironment] Initialization of ViProxyEnvironment for the proxy 10.1.10.6 (5c7f925e-999b-473e-9a99-9230f51d5ebb).

Если мы говорим про Direct SAN режим, то самое важное это корректность сопоставления LUNов с их номерами. В данном примере виден общий смысл происходящего: сначала получаем номера лунов, проверяем все подключённые к прокси луны на предмет нахождения идентичного и в случае успеха работаем с ним.

[04.06.2019 17:54:05] <01> Info [ProxyDetector] Searching for VMFS LUN and volumes of the following datastores: ['test_datastore'][04.06.2019 17:54:05] <01> Info [ProxyDetector] Datastore 'test_datastore' lun was found, it uses vmfs[04.06.2019 17:54:05] <01> Info [ProxyDetector] VMFS LUNs: ['NETAPP iSCSI Disk (naa.60a980004270457730244a48594b304f)'], NAS volumes: <no>...[04.06.2019 17:54:16] <01> Info [ProxyDetector] Proxy [VMware Backup Proxy]: Detecting san access level[04.06.2019 17:54:16] <01> Info [ProxyDetector] Proxy [VMware Backup Proxy]: disks ['6000C29C75E76E488EC846599CAF8D94566972747561','6000C29EA317A4903AFE2B7B038D3AD6566972747561','6000C29274D8E07AAE27F7DB20F38964566972747561','60A980004270457730244A48594B304F4C554E202020','6000C29EE0D83222ED7BFCB185D91117566972747561','6000C292083A3095167186895AD288DB566972747561','6000C2950C4F2CB5D9186595DC6B4953566972747561','6000C29BF52BB6F46A0E6996DA6C9729566972747561']...[04.06.2019 17:54:16] <01> Info [ProxyDetector] Proxy VMware Backup Proxy disk: , disk inquiry: SCSI Unique ID 60A980004270457730244A48594B304F4C554E202020 is accessible through san for ESXi with vmfs lun: NETAPP iSCSI Disk (naa.60a980004270457730244a48594b304f)

Эти же номера можно проверить самим. В vSphere клиенте в разделе Host > Configure > Storage devices, а в Windows посмотреть в стандартный Disk Manager. Все номера должны совпадать.

Репозиторий

В отличие от бекапа, реплика хранится непосредственно на сторадже хоста. Репозиторию Veeam отводится роль хранителя метаданных. Под каждое задание создаётся своя папка, где хранятся .vbk файлы, содержащие так называемые дайджесты. Чтобы найти конкретный, открываем лог таски и ищем [DigestsRepositoryAccessor]. Получаем путь, название репозитория и ID.

[15.09.2020 05:44:54] <19> Info [DigestsRepositoryAccessor] Creating new digests storage at [E:\Replicas\Replication_Job_4_7b409570-c4e1-424f-a0c5-b0b6e6e47272_vm-34412\2020-09-15T024444.vbk].[15.09.2020 05:33:54] <21> Info Setting repository 'Backup Repository 1' ('adf7fbb6-0337-4805-8068-77960414f406') credentials for backup client.

Если репозиторием выступает сетевая шара, то будет написан её путь:

[15.09.2020 06:50:53] <41> Info [DigestsRepositoryAccessor] Creating new digests storage at [\\172.17.12.57\test\Replicas\Replication_Job_4_7b409570-c4e1-424f-a0c5-b0b6e6e47272_vm-34432\2020-09-15T035033.vbk]

Если углубиться в поисках, то по Setting repository можно найти не только ID и название, но и под какой учёткой мы туда ходим. Если вы используете не одну учётку для всего на свете, то запросто можно промахнуться в визарде и долго искать причину, почему не удаётся подключиться к серверу.

[15.09.2020 06:50:02] <20> Info Setting repository 'DD share' ('36a89698-2433-4c1a-b8d3-901d9c07d03a') credentials for backup client.[15.09.2020 06:50:02] <20> Info Creds user name: ddve\sysadmin[15.09.2020 06:50:02] <20> Info Setting share creds to [\\172.17.12.57\test]. CredsId: [66de1ea7-7e89-48f6-bc73-61a4d1a7621e][15.09.2020 06:50:02] <20> Info Setting share creds to [\\172.17.12.57\test]. Domain: [ddve], User: [sysadmin]

WAN акселераторы

Получившая недавно второе рождение функция, которая бывает особенно актуальна для реплик. Проверить, работают акселераторы или нет, можно, найдя в логе джобы флаг <UseWan>. А по строке Request: SourceWanAccelerator можно получить информацию об ID используемых акселераторах.

[15.09.2020 05:32:59] <01> Info - - Request: SourceWanAccelerator: [WanAccelerator '8f0767e1-99ab-4050-a414-40edc5bebc39'], TargetWanAccelerator: [WanAccelerator '22fa299c-8855-4cf8-a6c7-6e8587250750'][15.09.2020 05:32:59] <01> Info - - - - Response: Subresponses: [Wan accelerator],[Wan accelerator]

В таск логе имена будут указаны уже в явном виде

[15.09.2020 05:33:54] <21> Info Using source WAN Accelerator KK-BB2[15.09.2020 05:33:54] <21> Info Using target WAN Accelerator 10.1.10.6

Что за второе рождение упоминалось в начале? Это так называемый High Bandwidth режим. Если раньше смысл от акселераторов был только на действительно медленных линках (очень медленных линках), то в v10 был введён новый режим, обеспечивающий прирост в производительности на скоростях до 100 Мб/с. Включается он отдельной галочкой, а в логах таски это видно вот по этим строкам:

 [15.09.2020 05:33:54] <21> Info Selecting WaTransport algorithm, input arguments: performance mode preferred: False, perf mode available on target WAN: False[15.09.2020 05:33:54] <21> Info Selecting WaTransport algorithm: selected classic mode

В первой строке указаны результаты проверки, включён ли необходимый режим на обоих WA мы видим, что нет, и выбираем классическую версию.

Просто полезные слова для поиска

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

Backup/Replication Job log

"> Error" или "> Warning" здесь что-то произошло, на что точно надо обратить внимание. Не обязательно всё сломалось именно тут, но что-то здесь точно произошло. Возможно даже пошло не так, как планировалось.

Job Options: здоровенная XML, где перечислены все настройки задания. После неё обычно идёт раздел VSS Settings, где перечислены настройки VSS.

[RetentionAlgorithm] момент отрабатывания ретеншн алгоритма. Тут удаляются ставшие ненужными точки или синтезируются новые.

[JobSession] Load: ботлнеки, про которые в нашем блоге есть отдельная статья.

Preparing point узнаём, в каком режиме создаётся бекап (инкремент, реверс инкремент или фул).

Starting agent узнаём, какой агент когда был запущен, и по его ID идём читать соответствующий ему лог.

VMware Job

[ProxyDetector] весь процесс выбора рабочих прокси и режима транспорта. Технически, в Hyper-V будет всё то же самое, только с гораздо меньшим количеством деталей.

[SanSnapshots] блок создания и работы с SAN-снапшотами.

VM task детальная информация о каждой конкретной машине в задании.

Hyper-V Job

VM tasks в отличие от VMware тут не будет исчерпывающей информации, однако как отправная точка для поиска истины самое то.

VM guest info много информации о гостевой машине и самом хосте. Однако имя машины надо предварительно посмотреть в секции Creating task, которая немного выше.

Task log

Starting Disk можно узнать, когда началась обработка конкретного диска. Очень полезно, если у машины их много, включён parallel processing и всё несколько запутано.

Operation was canceled by user где-то рядом ещё должно быть Stop signal has been received. Указывает на реальное время остановки бекапа и может означать всё что угодно. Если время подозрительно красивое, вроде 06:00:00, а юзер мамой клянётся, что ничего не трогал, то 99,99% установлено Backup Window и ваше время истекло.

Starting agent опять же, получаем ID нужного агента и далее смотрим прицельно.

Preparing oib указывает, готовится ли бекап машины в инкрементальном виде или фул.

.source. shows показывает, на каком сервере будет запущен передающий агент (Source Proxy).

.target. показывает, на каком сервере будет запущен принимающий агент (Repository/Target proxy).

VMware Task

VM information: Практически вся информация, которую можно узнать про целевую машину.

[VimApi] Create или [VimApi] Remove создание и удаление снапшотов. Через [VimApi] делается ещё несколько действий, так что не удивляйтесь.

Hyper-V Task

Files to process краткий список того, что будет забекаплено.

[RTS] весь процесс создания снапшотов и их удаления.

Agent log

Err | или WARN| то же самое, что и > Error > Warning. В Err действительно есть пробел перед палочкой, это не опечатка.

Traffic size размер всей переданной информации.

stat размер файла бекапа.

Backup service log

== Name показывает абсолютно все джобы и их текущее состояние (работает или остановлена). Между == и названием два пробела.

[Scheduler] Ready to start jobs: список джоб, которые будут запущены в соответствии с расписанием.

by user эта пометка делается, если юзер что-то сделал сам.

Backup copy job log

[OibFinder] покажет вам, какие репозитории и точки восстановления были исключены из обработки. Иногда даже может сказать, почему.

[CryptoKeyRecryptor] позволит понять, менялся ли на этом проходе юзер-пароль или энтерпрайз-ключ.

Surebackup

Backup point или Replica point время, когда была создана проверяемая точка.

[<vm name>] [PowerOnVm] [StableIp] моменты включения и выключения машин в лаборатории.

И на этом пока предлагаю остановиться. Так как список этот можно продолжать долго и никогда не закончить. Инженер техподдержки учится премудростям логочтения и устройства Veeam примерно три месяца, так что охватить всю широту наших глубин в рамках серии статей задача утопическая. Да и новая версия не за горами и часть информации может стать более невалидной.

Поэтому, если есть вопросы, то добро пожаловать в комментарии. Если есть предложение по написанию подобной статьи на какую-то конкретную тему адрес тот же, комментарии.

Засим позвольте откланяться и до новых встреч.

Казалось бы, такое простое действие: взять да восстановиться из бекапа, если где-то сломалось. Текущий уровень развития софта позволяет это cделать буквально в несколько кликов - и вы восхитительны. Возможно, даже никто не заметит, что была какая-то авария.

Но нет! Нет препятствий патриотам, как говорили в одном прекрасном фильме. Даже во время послеаварийных работ можно натворить такой дичи, что завтра ваша трудовая будет прибита двухсотым гвоздём к забору у проходной, а слава о ваших деяниях будет ещё долгим эхом ходить по просторам IT вселенной.

И вот о том, как не овеять себя славой самого могучего специалиста во веки веков, мы сегодня и поговорим. Шесть очевидных и не очень поводов задуматься. И да, при чтении не забывайте поднимать табличку "Сарказм" и помните - всё написанное ниже основано на реальных случаях.

Ты админ ты лучше знаешь, чего им надо!

И никто не вправе тебе указывать, в какой последовательности, насколько срочно и что именно надо восстанавливать. Да, можно прикинуться вежливым и для галочки обойти руководителей других отделов, чтобы составить план восстановительных работ на случай аварии, но зачем? Генеральный не шарит и подпишет что угодно, а на местах будут перетягивать одеяло на себя. Продавцы скажут, что их база самая важная. На складе будут твердить, что час без отгрузок - минус выручка за неделю. А на производстве так и вовсе удивятся такому банальному вопросу.

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

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

Не забивай голову мануалами. Всё знать невозможно

В конце концов вы за что деньги платили? Ладно бы софт был бесплатный, а железо собирал ты сам из подручных компонентов. В таком случае ещё можно как-то оправдать недельное вкуривание мануалов по настройке и оперированию. Но ты сначала купил софт для бекапа по цене чугунного моста, а потом ещё и здоровую СХД для интеграции, которая сожрала под два годовых бюджета. А сверху ещё и сеть отдельную проложил. Поэтому любому дураку понятно, что ничего сложнее Quick Start Guide читать не надо. Все эти толстенные мануалы, конечно, очень важны и полезны, но голова-то не резиновая. Нельзя в неё пихать всё подряд.

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

Также не вздумай вникать в подкапотное пространство тех приложений, которые понаставили на твои горячо любимые сервера. БД админ что-то там говорил о уже настроенных бекапах сторонним приложением? Ай, да не важно. Два бекапа всегда лучше, чем один. Тем более, что тебе надо настроить бекап вашего кластеризованного почтовика. Хотя чего там настраивать? Он же в кластере, и чего ему будет. Достаточно бекапить любую ноду и вся наука. Лучше пойти и переносом инфы на pass-through диски заняться.

Так что ничего сложнее операционки на уровне продвинутого сисадмина в памяти держать не надо. Тебе за это не платят.

Сейчас главное восстановиться, а куда и как - не суть важно

Если авария уже случилась, то первейшая наша цель - это восстановить данные и запустить критичные сервисы. Поэтому наш девиз в это тревожное время: Вижу цель, не вижу препятствий. Сейчас главное - скорость и быстрота реакции. Клик-клик - и вот уже бекап европейского сервера разворачивается где-то под Тверью. Не важно, что там дохлая площадка на полтора сервера, главное - побыстрее бы. Бекапы ведь именно там, значит и восстановится быстрее. Персональные данные европейцев? Ой, ну кому какая разница сейчас до ваших далёких GDPR и прочего. Нам же восстановиться надо. Хостинг в пять раз дороже, чем упавший? Да какая разница, потом мне ещё спасибо скажут за быстроту реакции. Мало места на дисках? Так вот это явно ерунда какая-то, можно и не восстанавливать. Сейчас главное - это восстановить прод!

Один для всех и все для одного!

Единые правила бекапа для всей инфраструктуры - это абсолютно нормально. Слабохарактерные здесь могут начать возражать, что бывают системы, выход из строя которых будет фатален, и для их защиты надо строить active-active кластера, делать резервирование и продумывать варианты репликации. Например, взять ту же сеть. Вы представляете, сколько будет стоить сделать двойное её резервирование? Это же надо рядом с одной сетью построить вторую такую же. А ведь от кривых рук админов мы и так защищены постоянными бекапом конфигов, чтобы иметь возможность в любой момент откатиться. Если сгорит какая-то sfpшка, то самый молодой твёрдо знает, в какой магазин бежать за новой, а наши поставщики готовы по звонку привезти нам хоть новое ядро сети. Ну а за те полчаса, пока они едут, ничего страшного не случится.

Хорошо, возразят другие, это было про совсем уж критические системы, без которых встанет натурально всё. А что с теми, где действительно можно часик подождать? Например, почтовик или сайт, на который можно быстро выкатить извинительную заглушку? Здесь главное - тоже не поддаваться на уговоры параноиков и не начать городить Active-Passive системы. Там ведь есть гора своих проблем с синхронизацией, например. Можно, конечно, построить систему, которая будет делать снапшоты по расписанию и позволять быстро откатываться с минимальными потерями. Но это опять деньги на лицензии и железо, работающее вхолостую. И по большому счёту это риски теоретические и защищающие от авось.

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

Disaster Recovery Plan Шредингера

С этим прекрасным документом есть ровно две противоположные проблемы. У одних его нет, другие его распечатывают, подписывают и прячут в сейф. В итоге как себя вести при аварийной ситуации, не знают ни первые, ни вторые. Первые оправдывают себя тем, что инфраструктура - вещь живая и постоянно меняется, а значит, придётся постоянно вносить изменения, согласовывать их, и так далее. Так что гораздо лучше будет не морочить себе голову бумажной волокитой, а довериться своим знаниям и не мешать людям работать. Они же профессионалы!

Вторые бумажной работы не боятся, тщательно всё документируют и в случае аварии шаг за шагом следуют плану. Ибо, как известно: если план подписал генеральный, значит, вся ответственность будет на нём, а сам план должен неукоснительно соблюдаться. Главное, чтобы этот документ напоминал локальную копию википедии: максимально подробные схемы включения абсолютно всего оборудования, схемы зависимости приложений, порядок загрузки машин, через какой порт кто с кем связывается, многочисленные проверки настроек и базовых тестов после включения. Словом, бюрократия 80 уровня. А если с последнего согласования были изменения или в середине отработки сценария всё пошло совсем не так, как описано, то это уже издержки производства. Виноватых найдём и покараем, главное - строго следовать плану. Больше бумаги чище все места.

Ходят слухи, что есть ещё вариант посредине, и некоторые не только пишут пошаговые инструкции, но и разрешают сотрудникам руководствоваться здравым смыслом при выполнении любых действий. А совсем мифические персонажи так ещё и тренинги проводят, наживую отключая целые системы и симулируя типичные инфраструктурные проблемы. Правда, неясно, кто таких маньяков на работу берёт.

Каждый должен знать своё место

Будет настоящим преступлением и растратой денег работодателя позволять сотрудникам отвлекаться от их основной работы в рамках трудового договора и вникать в деятельность коллег. Во-первых, это отвлекает самих коллег, не позволяя им трудиться в полную силу. А во-вторых, сам сотрудник тоже будет постоянно отвлекаться от своей работы, тем самым повышая шансы ошибиться. И в итоге у нас два человека, не работающие в полную силу. Поэтому совершенно недопустимо, чтобы условный сетевик плотно общался с условным инженером группы виртуализации. Так у вас ни сети нормальной не будет, ни внятно работающих виртуалок. Если у них возникает какой-то общий проект, замечательно оформляется запрос от одной команды к другой, формулируется ТЗ и работа ведётся строго по нему. А бесконтрольный обмен знаниями - это путь к хаосу.

И главное, от чего вас это спасёт: в случае аварии, если на месте не будет профильного специалиста, никто и не додумается залезать на его участок. Даже если он будет руководить действиями удалённо, лучше уж подождать пока он приедет, чем сломать всё ещё больше.

Вот такие вот шесть вредных советов.

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

А какие вредные советы для коллег добавили бы вы?

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

Лирическое отступление

Это только присказка, сказка впереди

В начале 2000-x я работал в IT-компании, которая выполняла несколько аутсорсинговых проектов для компании Integrated Genomics. Проекты были связаны с расшифровкой геномов простейших организмов. К примеру, одна из утилит искала фрагменты (праймеры) с определенными свойствами в геноме кишечной палочки. На входе утилиты была последовательность ДНК, загружаемая из публичной базы геномов ERGO и состоящая из азотистых оснований. На выходе таблица фрагментов и их позиция в цепочке ДНК. Далее эти фрагменты использовались биологами для синтеза геномов. Задача была сравнительно простой. Нужно было лишь позаботиться о том, чтобы программа не выжирала всю оперативную память довольно слабых машин, которые были у нас на тот момент. Сложность других проектов заключалась в том, что они находились на стыке трех дисциплин: биологии, математики и информатики. В тех случаях, когда алгоритм задачи был понятен, его реализация в программном коде не представляла трудности. Но когда сама задача была неопределенной, и не находилось никого кто мог бы ее формализовать, это был серьезный вызов.

Выяснилось, что для того, чтобы успешно решать такие задачи, нужны фундаментальные знания по биологии и высшей математике. Нас, молодых и горячих, это не остановило. Мы нашли англоязычную книгу по биоинформатике профессора Павла Певзнера и приступили к изучению. Поначалу повествование было легким и непринужденным. Во вступлении Павел рассказывал о том, как выживал в Москве в студенческие годы, и это было поистине приятное и расслабляющее чтение. Далее в первых главах речь шла про азотистые основания нуклеотидов ДНК аденин, гуанин, тимин и цитозин и про комплиментарность нуклеиновых кислот, а именно: как основания нуклеотидов способны формировать парные комплексы аденинтимин и гуанинцитозин при взаимодействии цепей нуклеиновых кислот. Было понятно, что такое свойство нуклеотидов играет ключевую роль в репликации ДНК. Я помню, что испытывал подъем и состояние потока, читая это объяснение, и мысленно представлял, как мы сейчас быстренько все это освоим (подумаешь, биология) и сможем брать более серьезные задачи. Мы даже думали о том, что сможем написать свой геномный ассемблер и взяться за расшифровку простейших геномов. Продолжаю читать книгу, и тут бах система уравнений на полстраницы без каких-либо объяснений. Из контекста подразумевалось, что эта система проще пареной репы, и любое объяснение будет оскорблением для читателя. Не было даже сноски для факультативного чтения. Я решил эту страницу пропустить, вернуться к ней позже и пока что продолжить читать дальше вдруг станет понятно. Перелистываю страницу а там еще одна система уравнений уже на всю страницу и скупое описание, часть слов из которого мы не нашли в словаре. Стало понятно, что эту область знаний на стыке геномики и математики нахрапом не возьмешь. Также стало понятно, почему подавляющее большинство коллег, с которыми мы взаимодействовали, имели биологическое и/или математическое образование. В конечном итоге, шаг за шагом погружаясь в основы геномики, нам удалось создать несколько программных продуктов, и тогда я в первый раз всерьез задумался о том насколько результативной и интересной может быть деятельность на стыке нескольких дисциплин.

С тех пор еще не раз мне довелось сменить сферу деятельности, и в каждом случае навыки разработчика служили трамплином для решения новых задач. Так произошло и с автоматизацией тестирования ПО.

Перспективы разработчика в автоматизации тестирования ПО

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

Исторически сложилось так, что в автоматизацию приходят специалисты с опытом в ручном тестировании ПО. В какой-то момент они осознают, что рутинные операции можно и нужно автоматизировать, либо просто желают попробовать себя в новом качестве. Опыт, привносимый ручными тестировщиками в проект автоматизации, бывает архиполезным. Никто лучше них не знает возможности и слабые места продукта, наиболее трудоемкие сценарии для тестирования, окружение, в котором работает продукт, а также пожелания пользователей и планы на следующие релизы. Как правило, хороший ручной тестировщик четко понимает, что именно он хочет автоматизировать, но с написанием автотестов порой возникают сложности. Почему? Потому что автотесты это такой же программный продукт, как и продукт, который они призваны тестировать. Нужно продумать архитектуру системы автотестов, механизмы их запуска (Continuous Integration, CI) и самое главное нужно писать хороший код. По факту, для ручного тестировщика это зачастую оказывается непросто. Ведь здесь требуется создать полноценный проект, который можно интегрировать в CI, изменять, расширять и переиспользовать. Для этого нужны способности к программированию, накопленный опыт и набитые шишки.

Ручной тестировщик с глубоким пониманием продукта и методик тестирования и разработчик с опытом программирования отлично дополняют друг друга. Первый силен в постановке задачи (use case -> test case), второй в ее реализации. Встает вопрос: почему среди автоматизаторов встречается много ручных тестировщиков? На это есть несколько причин:

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

Для разработчиков переход в автоматизаторы в некотором смысле разрыв шаблона: Вот я разрабатывал продукт, а теперь буду тестировщиком, который пишет автотесты какой же я теперь разработчик? Иными словами, есть опасение потерять квалификацию, превратиться в ручного тестировщика, а также нежелание глубоко погружаться в теорию и практику тестирования.

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

Опасение потерять в карьерном росте и зарплате.

Разберем эти моменты.

Автотесты это такой же продукт разработки, как и тот продукт, для которого эти автотесты создаются. Если разработчик идет на позицию автоматизатора в выделенную группу разработки автотестов, он остается на стезе написания программного кода. Да, ему надо иметь представление о тестировании ПО, но базовые знания можно сравнительно быстро получить, пролистав какое-либо руководство по тестированию ПО (например, вот эту книгу). Безусловно, автоматизатору нужно понимать продукт, для которого он пишет автотесты. Но освоить продукт на приемлемом уровне зачастую оказывается легче, чем научиться писать хороший код. Знания о продукте и методиках тестирования будут расширяться по мере ознакомления с багами, написанными на продукт, и общения с ручными тестировщиками. Разработчик не перестанет быть разработчиком, не превратится в ручного тестировщика. Это не его путь. Путь разработчика писать хорошие автотесты.

Задачи у автоматизатора интересные и зачастую сложные. В первую очередь стоит вспомнить про знаменитую пирамиду Фаулера. Модульные, интеграционные, end-to-end тесты подразумевают вдумчивый подход к структуре тестов и выбору инструментов в соответствии с функциональностью продуктов, для которых пишем автотесты. Если говорить о продуктах, разрабатываемых в Veeam, то автоматизатору понадобится работать с REST, WebDriver, Microsoft SQL Server, Amazon Web Services, Microsoft Azure, VMware vCenter, Hyper-V список не исчерпан. У каждого из облаков и гипервизоров свой API и свои скелеты в шкафу. Порой приходится писать код на различных языках программирования, использовать заглушки, семафоры, создавать свои обертки и т.п.

Одну и ту же задачу можно решить по-разному, и автоматизатор ищет наиболее эффективное решение. Вот лишь один из примеров сценарий, реализованный для продукта Veeam ONE. Один из компонентов продукта Business View, который позволяет группировать элементы виртуальной инфраструктуры по различным критериям. Критериев и вариантов их комбинирования очень много, поэтому проверка этой функциональности вручную занимает много времени. Написание автотестов в лоб с имитацией действий ручных тестировщиков было бы неэффективным: тесты для графического интерфейса десктопных приложений, как правило, сложны и трудоемки в разработке, являются хрупкими, их тяжело модифицировать, и выполняются они долго. Мы нашли другое решение: поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп. Это позволило нам в разумные сроки покрыть автотестами все свойства и операторы, задействованные в Business View.

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

Нужно обратить внимание на качество самих автотестов. Кто сторожит сторожей? Какому автотесту можно доверять? Автотест должен быть эффективным по критерию количество затраченных на него усилий / полученный результат, автономным, стабильным (нехрупким), быстрым, надежным (никаких false positive и false negative). В автотесте должен быть понятный, хороший код с точки зрения возможностей языка программирования, чтобы этот код можно было легко расширять и изменять.

Начинающий автоматизатор приступает к написанию простых тестов в соответствии с согласованными планами/подходами/инструментами. Решает самые простые задачи, учится справляться с трудностями, находить решения, обрастает знаниями и навыками. Задачи становятся все более серьезными, кредит доверия автоматизатору растет. Если автоматизатор не останавливается в своем росте, то спустя какое-то время он дорастает до разработки комплексных технических решений и более глубокого участия в обсуждении стратегии и приоритетов в разработке автотестов. В один прекрасный день он принимает под свое крыло начинающих автоматизаторов, которые хотят приносить пользу и расти.

Что в Veeam?

В компании Veeam мы будем рады новым боевым товарищам с опытом программирования на C# (например, web-интерфейсы, десктопные приложения, консольные утилиты и т.п.). У нас в Veeam есть много продуктов. Технологии в них могут различаться. В автотестах для нескольких продуктов мы опираемся на REST и WebDriver. Если у вас нет опыта с этими технологиями, но вы уверенно себя чувствуете в написании кода на C# и питаете интерес к автоматизации тестирования, то, возможно, мы также найдем точки соприкосновения.

Мы будем рады вашему резюме и паре абзацев о том, что вас привлекает в автоматизации, о ваших сильных сторонах и профессиональных планах. Пишите нам на ящик qa@veeam.com внимательно прочитаем. Если укажете в теме письма [Хабр] (например, [Хабр] Позиция автоматизатора), будет плюс в карму =)

Да пребудет с Вами Сила.

По мнению абсолютного большинства жителей этой планеты, разработчики это - какие-то зажравшиеся люди, которые сидят в своих уютных креслах, занимаются какой-то фигнёй и получают за это непомерные деньги. Эталонные тепличные условия и голубая мечта, которая выродилась в пренебрежительное Войти в айти. Но если предположить, что всё действительно так, как принято считать - и стул удобный, и денег платят много, и работа интересная - то почему же программисты, как и все остальные люди, иногда меняют место работы? Может быть, недостаточно платили? Или кресло было не такое удобное? Что-то же должно побудить человека, у которого всё хорошо (по мнению окружающих), выйти из зоны комфорта и пойти искать новое место работы. И что именно он ищет на этом новом месте? Давайте поговорим об этом. И да, многое здесь может показаться банальным, но почему-то достаточное количество людей предпочитают не брать в расчёт и половину из этих банальностей. Или делают вид, что им всё равно.

Предметная область

Современное IT завалено технологиями. Настолько завалено, что уже не знаешь, за что хвататься, чтобы оставаться в тренде, и есть ли вообще смысл в нём оставаться. Всё бросить и пойти в серверлесс? Сосредоточиться на распиле монолитов на микросервисы? А ведь ещё буквально вчера анонсировали очередной ЯП_name, и он выглядит неприлично привлекательно.

Где правильный ответ, не знает никто, и только время покажет. Понятно только одно - если тебе интересно ковырять UI на JS, не надо идти работать туда, где тебе предлагают 90% времени тратить на C++ бэкенд. Тебе нравятся крутые алгоритмические штуки пополам с математикой? Тогда вряд ли ты будешь особо счастлив в команде, рисующей веб формочки.

Для многих это сюрприз, но под 90% современной разработки - это безумная корпоративная скука, а делаем мы приложения, которые обычным людям, за пределами этих корпораций, совершенно не интересны. Если ты сможешь описать разрабатываемый тобой продукт далёким от IT родственникам, просто показав пальцем на приложение в их телефоне, то тебе несказанно повезло. А ведь кому-то такая возможность будет важнее всего остального.

Репутация продуктов и самой компании

Как все мы понимаем, ничего в этом мире не появляется просто так из воздуха. Что-то нам нравится, что-то нет, а к чему-то мы равнодушны. Вот возьмём, например, баннерную сеть, показывающую тотализаторы, вебкам, инфоцыган и прочее уверенно блокируемое адблоком. Вполне себе модные веб-технологии, передовые штуки в проде, интересные задачи, над которыми трудится молодой (не факт) и дружный (ещё более не факт) коллектив, состоящий из разработчиков, тестировщиков и дизайнеров. Плоды своей работы им помогает продавать отдел продаж, продакты думают над стратегией развития, а бухгалтерия следит за деньгами. То есть всё ровно так же, как и в любой другой белой IT компании. Просто здесь продукт - это баннерная сеть с порнухой. Это ни хорошо, ни плохо, просто когда кого-то это может смутить, другой поинтересуется только регулярностью выплаты зп, соцпакетом и офисными удобствами.

Отзывы бывших и текущих сотрудников

Нет среди нас таких людей, кто не читал бы отзывы о потенциальном работодателе. И практически нет никого, кто не попадал бы в их ловушку. Тут важно понимать, что в подавляющем большинстве отзывы пишут исключительно раздражённые люди, которые не смогли пройти собеседование, несмотря на всю свою гениальность и ясноокость (им так мама сказала). Кто в этом виноват? Конечно же, тупое собеседование, тупые вопросы, тупой интервьюер, тупой карандаш и тупое что угодно, кроме провалившегося кандидата. Отличные и ценные отзывы, иногда даже весело написанные, однако смело их пропускаем и не обращаем внимания.

Следующая немалая часть отзывов пишется людьми, которые действительно работали в данной компании, но занимались чем-то, не связанным с IT. Продажи, маркетинг, АХО и так далее. На эти эпистолярии уже можно потратить своё время, однако надо постоянно напоминать себе, что эти люди жили в другом мире, где есть KPI завязанные на количество продаж, конвертация кликов и прочие увлекательные штуки, от которых разработчики бесконечно далеки. Но на какие-то общие вещи, типа описание офиса, социальных программ и всего в этом духе стоит обратить внимание.

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

Количество проектов в активной стадии разработки

Есть такой замечательный (без шуток) язык COBOL. Один из первых языков программирования, созданный аж в начале шестидесятых. И за счёт этого на нём писано-переписано столько бизнес-логики, что никакой Java в страшном сне не снилось. А вот что не снилось в страшном сне нам, так это то, что огромное количество этих приложений продолжает успешно функционировать в проде огромных компаний. Банкиры, финансисты, транспорт с логистикой и так далее. Если думаете что я шучу, то вот вам для посмеяться проект от IBM для сборки контейнера с кодом на коболе внутри.

Это я к чему: есть целые компании, которые занимаются поддержкой и развитием (если это так можно назвать) подобных вещей. За это платят хорошие деньги, так что почему бы этим и не заниматься? В таких компаниях вечный день сурка и не покидающее ощущение стабильности. Будет ли там ветер перемен и шанс сделать что-то красивое и великое с нуля? Скорее всего, нет.

Поэтому прикидываем в голове, что нам интересней: вальяжно бежать многолетний марафон к цели, которая будет бесконечно удаляться, или же раз в неделю стартовать забег на стометровку, которая может закончиться пеной у рта. И если сейчас у вас в голове промелькнула мысль вроде Ну каким же надо быть недалёким человеком, чтобы выбрать другой вариант, значит, реальность приготовила для вас ещё один сюрприз.

Возможность смены проекта

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

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

Социальная программа

Как есть семь смертных грехов в резюме (коммуникабельность, обучаемость, стрессоустойчивость и так далее), так давно уже есть некий гигиенический уровень обеспечения комфортной работы в IT-сегменте. На предлагающих работать без оформления и соблюдения ТК уже смотрят как на умалишённых. Отсутствие бесплатного кофе и печенья для многих повод встать и уйти с собеседования (ну или отключиться от зума, если речь о современных реалиях). ДМС, оплачиваемые поездки на конференции, курсы английского, проведение митапов и тренингов, способы как-то отвлечься от рабочей рутины и разгрузить мозги. Всё что угодно, только приходи и работай.

Но человек - существо интересное и легко приспосабливается к окружающим условиям. А потом начинает считать их нормой. На кофе скидываемся сами? Странно, конечно, ну ладно. У стула отвалилась спинка, а новые будут покупать только через год? Ну ладно, прикручу как-то скотчем пока. Со следующей недели туалетную бумагу приносим сами? Ну наверно с деньгами у компании сейчас туго, поэтому сами принесём, ничего страшного. Так что никогда не будет лишним узнать, а как оно происходит у других. Вполне вероятно, что пока тебе годами обещают расширение списка клиник входящих в ДМС, с пяти до десяти, у других в ДМС давно вписаны дети и половина родственников.

Жаль только, что иногда люди воспринимают соцпакет как приглашение залезть на шею и свесить ножки. Не надо так. Любое сотрудничество должно быть взаимовыгодным.

Оплачиваемые переработки

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

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

Но, к сожалению, некоторые руководители предпочитают упускать этот момент. Ну или делают вид, что упускают. И по-прежнему уверены, что мы же тут одна команда, мы же работаем во благо компании, она нам этого не забудет и будет очень благодарна. Но мы выросли и хотим сами выбирать, на что нам тратить своё свободное время. Мы не меркантильные сволочи, которые только спят и видят, как вытрясти побольше денег из работодателя. Нет, мы готовы и за кодом посидеть на выходных, просто мы хотим потом получить компенсацию за пропущенный выходной. Может быть, в натуральном виде (отгулом в удобное мне время), а может быть, и деньгами. Но уж точно не мотивацией уровня Работать в нашей компании большая честь.

Поэтому добивайтесь в прямой форме ответа на вопрос А что тут у вас с переработкам?. В этом нет ничего постыдного или неудобного. Мы тут на работу устраиваемся и хотим обговорить все условия на берегу. Это нормально и, самое главное, правильно с обеих сторон.

Команда и руководство

Рыба гниёт с головы, а команда - из-за самодурства её руководства. Если в офисе принято соблюдать цветовую дифференциацию штанов и при входе в кабинет делать три раза Ку!, тут уж каждый должен сам для себя решать.

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

Да и с командой будет не лишним заранее познакомиться хотя бы мельком и в общих чертах. Осталось придумать, как это реализовать. Пока тебя собеседуют и офера на руках нет, то будет несколько странно водить каждого человека на показ, будто невесту на выданье. Вот это твои потенциальные коллеги, вот это твоё потенциальное место. А вот это проект, который мы тебе не дадим, потому что через неделю напишем, что ты нам не подходишь. Но если всё же получается реализовать такую идею хотя бы на последнем собеседовании (если их несколько), даже если просто сходить с командой на обед, то это реальный бонус.

Офис

Этот пункт состоит из двух частей. Как и сам офис. Из внешней и внутренней.

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

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

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

Зарплатушка

И сестра её - премия. Долго мы шли к этой теме, хотя кажется, что деньги - это крайне важно. Сейчас объясню, почему так получилось.

Ни для кого не секрет, что на сегодняшний день работа программистов оплачивается весьма и весьма хорошо. Конечно здесь бывают пограничные случаи, когда имея зп в (условно) 300к, на следующий день 270 из них уходят на кредиты/ипотеки/кружки детям, и мы обречены выслушивать стоны про несправедливо маленький уровень оклада. Но если откинуть такие экстремумы, в сухом остатке у нас получается, что программист, существующий в рамках текущего рынка труда и здраво относящийся к деньгам, вполне может себе позволить не сильно задумываться о конкретной дате ближайшей выплаты зп и знании точной суммы своего оклада. Грубо говоря, приходя в магазин за продуктами, новыми штанами и прочими обиходными товарами, он всегда уверен, что деньги на карточке у него есть и он может не слишком сильно себя ограничивать в выборе. А то и вовсе не ограничивать. Когда встаёт вопрос о покупке чего-то более дорогого, тут уже надо или поднакопить, или взять кредит. Но опять же, это будет лишь вопрос о выделении исключительно комфортной суммы в месяц, которая будет откладываться на обеспечение этой цели и которая никак не повлияет на привычный образ жизни. И это прекрасно.

И тут появляется интересная проблема: а если тебе и так живётся комфортно и на всё хватает, то будет ли банальное увеличение зп достаточным стимулом для смены места работы? Давайте только уточним, что речь здесь не идёт про вырожденный случай, когда к текущей зп приписывают сзади нолик. Или два. Тут нервы у кого угодно не выдержат. Нет, речь идёт про рыночные 10-15% прироста. Да, конечно, всегда есть и колбаса вкуснее, и машина красивей и прочие увлекательные вещи, для которых надо увеличивать свой доход. Однако сами по себе деньги перестали быть самоцелью для очень многих. Поэтому они и не на первом месте у многих разработчиков. Хотя их роль никто не пытается приуменьшать.

Технологический стэк

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

Техническое оснащение

Совершенно нелишним будет разузнать про железо, с которым придётся работать. Обещание выдать новый мак - это прекрасно, но какого он поколения и как часто происходят обновления? Если в первый день дадут ноут с i5 шестого поколения, это недоразумение на пару месяцев или ближайшие три года? А что происходит, если нужна новая железка на стейджинг? А если две и не самые простые?

Хотя тут главный вопрос в удобстве работы. Если для твоего текущего проекта не нужны безумные гигагерцы и терабайты (ну вдруг ты пишешь в блокнотике на том самом коболе), то и гнаться за топовым железом смысла нет. Вот если проект поменяется, а возможности оперативного апгрейда под его нужды нет, вот тогда это проблема.

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

Релокационный пакет

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

Релокации бывают разные. Можно переезжать между городами в рамках одной страны, а можно менять страну. Можно ехать одному, а можно ехать вместе с женой, двумя детьми и тремя котами. Поэтому, если вам предстоит релокация, к этой части надо подходить максимально въедливо и просить показать конкретные политики и приказы, чтобы потом не оказалось Ой. Хотя тут может быть проблема, что это всё документы, предназначенные только для глаз сотрудников. Но тут уже вопрос к HR и их умению давать информацию без разглашения конфиденциальных подробностей.

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

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

Поэтому лови шпаргалку по релокационным вопросам. Первым делом спроси вторую половинку (если она есть), что она думает о переезде в предлагаемую страну/город. Программисту зачастую всё равно, где писать код и на каком языке говорят за окном. А вот его семье это очень важно. Затем узнай, в чём конкретно заключается визовая поддержка. Они сами подадут на визу или тебе везде бегать самому? Сделают визу только сотруднику или всей семье? Какие именно визы и какие права они дают? Спроси про помощь с поиском жилья, про оплату билетов, подъёмные и юридическую помощь на месте. Ну и не лишним будет спросить на тему перевозки вещей, и есть ли какая-то программа адаптации для твоей семьи. Ну там, курсы языковые, кружки по интересам и всё такое прочее.

Может, про это отдельную статью написать, что скажете?

График

Вопрос стал трижды актуален благодаря пирожку с ковидлом, который мы все едим уже больше года. Насколько надо быть привязанным к офису? Могу ли я сам выбирать время, когда приходить на работу, и в каких пределах? Или, может, я буду лучше сидеть дома, а в офис приходить, только если действительно надо. А может, согласимся на удалёнку и останемся друзьями? Прямо сейчас вопрос крайне увлекательный, и только время рассудит нас.

Тотальный контроль

Знаете что такое чайка-менеджмент? Это шуточное название ужасной модели управления, когда начальник, испытывая отеческую заботу, считает своим долгом внезапно врываться в кабинет, хаотически выдавать ЦУ, поругать провинившихся и так же внезапно свалить в закат. То есть поведение типичной чайки: прилетела, поносилась кругами, покрякала, обгадила всё вокруг и улетела, оставив после себя недоумевающие взгляды.

А чтобы ещё больше самоутвердиться, сотрудников просят писать ежедневные отчёты, обкладывают горой нелепых регламентов и на сладкое скриншотят их экраны с последующей публичной поркой слишком часто открывающих стековерфлоу.

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

____________________________________________

Вот примерно такой у меня список получился. Если считаете, что надо обязательно дополнить его ещё одним пунктом - смело пишите в комментарии. Хотите поспорить - рецепт аналогичный. Всё вообще не так - тем более проследуйте данным маршрутом.

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

Общение с людьми всегда было моей профессией и увлечением. Сначала я училась на журналиста, потом работала пиарщиком, после бизнес-аналитиком в IT. В работе с любой аудиторией важно найти правильный подход и выстроить эффективную коммуникацию. Мой будущий ребенок не стал исключением. Шел пятый месяц беременности, а я еще не знала ни имени, ни пола (на узи он тщательно крутил фиги и отказывался деанонимизироваться), зато успела познакомиться с дивным новым миром, где полыхали дискуссии о преимуществах памперсов, пользе грудного вскармливания и лучших педагогических методиках. Оказалось, ребенка мало родить, его ещё иногда надо кормить и когда-то отдать в школу. Нужно еще и правильно с ним говорить, играть, развивать и выращивать.

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

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

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

Эксперимент Гарри Харлоу, в ходе которого детенышей макак отлучали от матерей в раннем возрасте, подтвердил, что в отсутствие привязанности почти не развиваются навыки общения, возрастает агрессия, затухает или исчезает материнский инстинкт у взрослых особей. Привязанность позволяет развиваться префронтальной коре головного мозга, которая прогнозирует результаты и последствия, определяет действия, необходимые для достижения определенной цели, подавляет убеждения, которые могут вызвать социально неприемлемые результаты одним словом, делает человека разумного из человека прямоходящего.

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

Привязанность последовательно строится на 6 основах:

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

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

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

• Значимость на этом уровне дети ищут подтверждение того, что важны своему взрослому.

• Чувства привязанность посредством эмоций. Ребенок начинает любить и осознанно отдает свое сердце взрослому.

• Быть познанным последний уровень привязанности, потребность в понимании и признании. Ребенок делится со взрослым своими секретами и интересами.

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

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

Как именно родители могут воплотить в жизнь принципы ответственного родительства? Давайте рассмотрим основные положения:

Возьмите ответственность за отношения на себя.

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

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

Сохраняйте связь на расстоянии

Помогите ребенку сохранить чувство близости, пока вы в разлуке. Гордон Ньюфелд называет эту практику bridging наведение моста, связывание. Это интуитивные действия, доступные и используемые большинством. Примером могут стать влюбленные, поддерживающие связь на расстоянии с помощью милых записок, памятного аксессуара или одинаковой одежды.

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

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

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

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

Воздержитесь от дисциплины, которая разделяет

Дисциплинарные практики, построенные на разделении ребенка с его значимым взрослым, приводят к потере чувства близости, заставляют ребенка закрываться и, как следствие, избегать крепкой привязанности в дальнейшем. Такие методы дисциплины, как стояние в углу, изгнание в другую комнату, тайм-ауты или Я пойду, а ты оставайся, раз не слушаешься, Сейчас придет чужой дядька и заберет тебя манипулируют самым важными чувствами любви и безопасности и могут глубоко ранить ребенка.

Безусловно, дети способны вывести из себя кого угодно, и вы имеете полное право на негативные эмоции и раздражение, но позвольте вашему ребенку чувствовать себя в безопасности. После ссоры объясните, что вы раздосадованы и хотите побыть наедине. Запланируйте прогулку на 10 минут дольше, чтобы маленький зодчий мог закончить свой песочный замок без понуканий. Обойдите стороной тот магазин, где ребенок непременно потребует двадцатую машинку, и закажите продукты с доставкой на дом. Одним словом, сберегите ваш ресурс для действительно серьезных ситуаций например, когда ваш малыш первый раз взорвет химическую лабораторию в школе или сообщит, что решил жениться.

Удовлетворяйте жажду привязанности

Позвольте ребенку получить столько вашей любви, сколько ему необходимо.

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

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

Так и наши дети: если они не уверены в нашей привязанности, они будут цепляться за нас, требовать постоянного подтверждения нашей любви и никогда не чувствовать себя расслаблено.

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

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

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

Создавайте правила и традиции

Правила и традиции в любом социуме исполняют роль сохранения самых важных ценностей. Вы можете использовать это и в вашей семье. Определите, какие правила действительно важны для вашей семьи и какие ценности вы хотите отстоять с их помощью. Зачастую давление социума на родителей выражается как раз с помощью нельзя и не положено, и нам приходится мучительно отказываться от совместного сна или откладывать поступление в школу, страдая угрызениями совести. Но, возможно, в такой ситуации вы спросите себя: Это действительно нужно мне и моему ребенку? Или это нужно обществу? Такая валидация семейных правил поможет вам объяснить их ребенку, а ему, в свою очередь, их соблюдать.

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

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

Помимо общей стратегии Гордон Ньюфелд предлагает несколько прикладных техник общения:

• Завладевайте вниманием

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

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

• Эмоциональная связь

Эффективному общению может помочь эмоциональная связь, которая соединит ребенка с вами, позволит ему доверять вам и прислушиваться к вашим словам. Для создания такой связи Гордон Ньюфелд рекомендует укреплять рефлекс привязанности: создавать благоприятную атмосферу, которая позволит ребенку не бояться и быть откровенным, чувствовать себя значимым и интересным для вас. Этого можно достигнуть, проявляя внимание и интерес к ребенку и его жизни, поддерживая физический контакт (объятия, взгляд, пожатие рук) и подчеркивая вашу похожесть (мне нравится то, что нравится тебе, я испытывала такие же чувства в подобной ситуации). Благодаря этой связи ребенок сможет быть самим собой в общении с нами.

• Позвольте положиться на себя

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

• Будьте стрелкой компаса для вашего ребенка

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

Секрет родительского воспитания, по мнению Гордона Ньюфелда, заключается не в том, что делает родитель, а в том, кем он является для ребенка.

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

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

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

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

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

Автор: Юлия Балабанова (Veeam), бизнесс аналитик.

Использованные источники:

Гордон Ньюфелд, Габор Матэ Не упускайте своих детей, Ресурс, Москва 2012

Ольга Писарик Привязанность жизненно-важная связь, Сборник статей, https://alpha-parenting.ru/library/broshyura/

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

Как вы думаете, что вообще такое эти "логи"? По мнению большинства, логам любого приложения должна быть отведена роль этакой всемогущей сущности, которая большую часть времени прозябает где-то на задворках, но в нужный момент появляется из ниоткуда в сияющих доспехах и всех спасает. То есть в них должно быть всё, начиная с малейших ошибок в каждом компоненте, до отдельных транзакций базы. И чтобы после ошибки сразу писалось как ещё исправить. И умещаться это всё должно в пару мегабайт, не больше. Это же просто текст! Не могут текстовые файлы занимать десятки гигабайт, я где-то это слышал!

Итак, логи

В реальном мире логи это всего лишь архив диагностической информация. И что там хранить, откуда брать информацию для хранения и насколько подробной она должна быть, решать самим разработчикам. Кто-то идёт по пути минимализма храня записи уровня ВКЛ/ВКЛ, а кто-то старательно сгребает всё до чего только смог дотянуться. Хотя есть ещё и промежуточный вариант с возможностью выбора так называемого Logging Level, когда ты сам указываешь насколько подробную информацию ты хочешь хранить и насколько у тебя много лишнего места на дисках =) У VBR таких уровней аж шесть, кстати говоря. И, поверьте, вы не хотите видеть что происходит при максимально подробном логировании со свободным местом на вашем диске.

Хорошо. Мы примерно поняли что хотим сохранять, но встаёт законный вопрос: откуда брать эту информацию? Часть событий для логирования, конечно, формируем мы сами нашими внутренними процессами. Но что делать, когда происходит взаимодействие с внешней средой? Чтобы не скатываться в кромешный ад из костылей и велосипедов, Veeam имеет тенденцию не изобретать уже изобретённые изобретения. Всегда, когда есть уже готовое API, встроенная в систему функция, библиотека и т.п., мы отдадим преимущество готовым вариантам, прежде чем начинать городить свои хитроумные решения. Хотя последних тоже хватает. Поэтому при анализе логов важно понимать, что львиная доля ошибок приходится на сообщения от сторонних API, системных вызовов и прочих библиотек. В данном случае роль VBR сводится к форварду этих ошибок в файлы логов as is. А основная задача пользователя - научиться понимать, какая строчка от кого, и за что этот кто отвечает. Поэтому, если код ошибки из лога VBR приводит вас на страницу MSDN, это нормально и правильно.

Как мы договорились ранее: Veeam это так называемое SQL-based приложение. А значит все настройки, вся информация и вообще всё, что только необходимо для нормального функционирования всё хранится в его базе.Отсюда простая истина: то, чего нет в логах, скорее всего есть в базе. Но и это не серебряная пуля: некоторых вещей нет ни в локальных логах компонентов Veeam, ни в его базе. Поэтому надо научиться изучать логи хоста, логи локальной машины и логи вообще всего, что участвует в процессе бекапа и рестора. А бывает и так, что нужной информации нет вообще нигде. Таков путь.

Несколько примеров таких API

Данный список не ставит себе целью быть исключительной полноты, так что не надо в нём искать истину в последней инстанции. Его задача - лишь показать самые частые сторонние API и технологии, используемые в наших продуктах.

Начнём с VMware.

Первым в списке будет vSphere API. Используется для аутентификации, чтения иерархии, создания и удаления снапшотов, запроса информации о машинах и многого (очень многого) чего другого. Функционал решения очень широкий, поэтому всем желающим могу порекомендовать VMware vSphere API Reference для версии 5.5 и 6.0. Для более актуальных версий всё просто гуглится.

VIX API. Чёрная магия гипервизора, для которой есть отдельный список ошибок. VMware API для работы с файлами на хосте без подключения к ним по сети. Вариант последней надежды, когда надо положить файлик в машину, до которой нет более лучшего канала связи. Представляет из себя боль и страдание, если файлик большой, а хост загружен. Но тут работает правило, что даже 56,6 Кб/с это лучше чем 0 Кб/с. В Hyper-V подобная штука называется PowerShell Direct. Но так было только до появления

vSpehere Web Services API Начиная с vSphere 6.0 (примерно, т.к. впервые этот API был представлен на версии 5.5) используется для работы с гостевыми машинами и уже практически везде вытеснил VIX. По сути, это ещё один API для управления vSphere. Интересующимся могу посоветовать изучить отличный мануал.

VDDK (Virtual Disk Development Kit). Библиотека, о которой частично говорилось в этой статье. Используется для чтения виртуальных дисков. Когда-то давно была частью VIX, однако со временем вынесена в отдельный продукт. Зато на правах наследника использует те же коды ошибок, что и VIX. Но по какой-то причине в самом SDK нет никакого описания этих ошибок. Поэтому опытным путём было выяснено, что ошибки VDDK с другими кодами -- всего лишь трансляция из бинарного в десятичный код. Состоит из двух частей первая половина являет собой недокументированную информацию о контексте, а вторая часть -- традиционные VIX/VDDK ошибки. Например, если видим:

VDDK error: 21036749815809.Unknown error

То смело конвертируем это в hex и получаем 132200000001. Неинформативное начало 132200 просто откидываем, а остаток и будет нашим кодом ошибки (VDDK 1: Unknown error).Про самые частые VDDK errors как раз недавно была отдельная статья.

Теперь посмотрим на WIndows.

Здесь всё самое нужное и важное для нас можно найти в стандартном Event Viewer. Но есть одна загвоздка: по давней традиции Windows логирует не полноценный текст ошибки, а только её номер. К примеру, ошибка 5 -- это Access denied, а 1722 -- это The RPC server is unavailable, ну и 10060 -- это Connection timed out. Конечно, здорово, если ты помнишь самые известные, однако как быть с доселе невиданными?

А чтобы жизнь совсем мёдом не казалось, ошибки ещё и в шестнадцатеричном виде хранятся, с префиксом 0x8007. К примеру, 0x8007000e -- это на самом деле 14, Out of Memory. Зачем и для кого так было сделано - тайна, покрытая мраком. Однако полный список ошибок можно скачать бесплатно и без СМС из девцентра.

Кстати, иногда встречаются и другие префиксы, а не только 0x8007. В такой печальной ситуации для понимания HRESULT (result handle) нужно ещё глубже влезать в документацию для разработчиков. В обычной жизни делать я вам такое не советую, но если вдруг прижали к стенке или просто интересно, теперь вы знаете, что делать.

Но товарищи в Microsoft несколько сжалились над нами и явили миру утилиту ERR. Это небольшой кусочек консольного счастья, который умеет переводить коды ошибок на человеческий без использования гугла. Работает она примерно так.

C:\Users\root\Desktop>err.exe 0x54f# for hex 0x54f / decimal 1359  ERROR_INTERNAL_ERROR                                           winerror.h# An internal error occurred.# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f# for hex 0x54f / decimal 1359  ERROR_INTERNAL_ERROR                                           winerror.h# An internal error occurred.# 2 matches found for "0x54f"

Возникает законный вопрос: а чего ради мы в логи сразу не пишем расшифровку, а оставляем эти таинственные коды? Ответ в сторонних приложениях. Когда ты сам дёргаешь какой-то WinAPI вызов, то расшифровать его ответ не составляет труда, ибо для этого даже есть свой специальный WinAPI вызов. Но как было уже сказано, в наши логи попадает всё, что только приходит к нам в ответах. И тут уже для расшифровки пришлось бы постоянно мониторить этот поток сознания, выцеплять из него куски с ошибками винды, расшифровывать их и вставлять обратно. Скажем честно, не самое увлекательное занятие.

Windows File Management API всячески используется при работе с файлами. Создание файлов, удаление, открытие на запись, работа с атрибутами и прочее, и прочее.

Упомянутый выше PowerShell Direct как аналог VIX API в мире Hyper-V. К сожалению, не такой гибкий: масса ограничений по функциональности, работает не с каждой версией хоста и далеко не со всеми гостями.

RPC (Remote Procedure Call) Я думаю, что нет ни одного человека, работавшего с WIndows, кто бы не видел ошибок, связанных с RPC. Несмотря на популярное заблуждение, это не какой-то единый протокол, а любой клиент-серверный протокол, удовлетворяющий ряду параметров. Однако если в наших логах есть ошибка RPC, в 90% случаев это будет ошибка от Microsoft RPC, который является частью DCOM (Distributed Component Object Model). В сети можно найти огромное количество документации на эту тему, однако львиная её доля довольно сильно устарела. Но если есть острое желание изучить тему, то могу рекомендовать статьи What is RPC?, How RPC Works и длиннющий список ошибок RPC.

Основные причины возникновения RPC ошибок в наших логах - это неудавшиеся попытки взаимодействия между компонентами VBR (сервер > прокси, например) и чаще всего из-за проблем со связью.

Топовый топ среди всех топов - это ошибка The RPC server is unavailable (1722). Если по-простому, то клиент не смог установить соединение с сервером. Как и почему - единого ответа нет, но обычно это проблема с аутентификацией или с сетевым доступом до порта 135. Последнее характерно для инфраструктур с динамическим назначением портов. На эту тему есть даже отдельная КВ. А у Microsoft - объёмный гайд по поиску причин неисправности.

Вторая по популярности ошибка: There are no more endpoints available from the endpoint mapper (1753). RPC клиент или сервер не смогли назначить себе порт. Обычно возникает, когда сервер (в нашем случае гостевая машина) был настроен на динамическое выделение портов из узкого диапазона, который закончился. А если заходить со стороны клиента (в нашем случае VBR-сервера), это значит, что наш VeeamVssAgent или не запустился, или не был зарегистрирован как RPC интерфейс. На эту тему так же есть отдельная КВ.

Ну и чтобы завершить Топ-3 ошибок RPC, вспомним RPC function call failed (1726). Появляется, если связь была установлена, но RPC запросы не отрабатывают. Например, мы запрашиваем информацию о статусе VSS (вдруг там прямо сейчас шедоу копи делается, а мы лезть пытаемся), а в ответ нам тишина и игнор.

Windows Tape Backup API нужен для работы с ленточными библиотеками или приводами. Как я упоминал в начале: писать свои драйвера и мучиться потом с поддержкой каждого устройства нам нет никакого удовольствия. Поэтому у вима нет никаких своих драйверов. Всё через стандартный API, поддержку которого реализуют сами вендоры железа. Так ведь намного логичней, правда?

SMB/CIFS Все по привычке пишут их рядом, хотя далеко не все помнят, что CIFS (Common Internet File System) - это просто частная версия SMB (Server Message Block). Так что ничего плохого в обобщении этих понятий нет. Вот Samba - это уже Linux\Unix реализация, и там есть свои особенности, но это я отвлёкся. Что тут важно: когда Veeam просит записать что-то по UNC пути (\server\directory), сервер использует иерархию драйверов файловой системы, включая mup и mrxsmb, для записи на шару. Соответственно, ошибки генерировать будут тоже эти драйверы.

Никак нельзя обойтись без Winsock API. Если что-то надо сделать по сети, VBR работает через Windows Socket API, в народе известный как Winsock. Так что если видим в логе связку IP:Port, это оно. В официальной документации есть неплохой список возможных ошибок.

Упомянутый выше WMI (Windows Management Instrumentation) - это некое всемогущее API для управления всего и всем в мире Windows. Например, при работе с Hyper-V практически все запросы к хосту происходят именно через него. Словом, вещь совершенно незаменимая и очень мощная в своих возможностях. В попытках помочь выяснить, где и что сломалось, очень помогает встроенная тула WBEMtest.exe.

И последний по списку, но совершенно не последний по значимости - VSS (Volume Shadow Storage). Тема настолько неисчерпаемая и загадочная, насколько много по ней написано документации. Shadow Copy проще всего понимать как особый тип снапшота, которым по сути он и является. Благодаря ему в VMware можно делать application-consistent бекапы, а в Hyper-V вообще чуть ли не всё. У меня есть в планах сделать отдельную статью с некой выжимкой по VSS, но пока можете попробовать почитать это описание. Только осторожно, т.к. попытка понять VSS с наскока может привести к травмам головного мозга.

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

Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одного облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.

Для начала повторим банальное, но важное утверждение: облака - не серебряная пуля и не ответ на главный вопрос жизни, Вселенной и всего такого. Облако - это просто элемент инфраструктуры, который позволяет вам решать возникшие у вас задачи. И если сами облака работают уже достаточно стабильно и предсказуемо, то на идеологическом уровне всё ещё имеются проблемы. И основная заключена в том, что, начав использовать облако, вы получаете как бы две инфраструктуры: классическую и облачную. То есть каждая управляется своими инструментами и из разных мест, хотя всё IT сообщество последние годы стремится исключительно к унификации. Значит облако должно быть не обособленным куском инфраструктуры, а просто одной из её частей и не требовать к себе внимания больше, чем все остальные.

Лет 10-12 назад все боялись виртуализации и смотрели на неё исключительно как на диковинку заморскую. А знаете, какими были первые внедрения виртуальных машин? Исключительно в качестве DR (disaster recovery) площадок. То есть технология новая, чего от неё ждать - непонятно, и перевозить туда продакшн боязно. Поэтому мы её пока будем изучать в лабораторных условиях, а на случай аварии пусть стоит в углу готовая к бою копия инфраструктуры. Потом могла или авария случиться, или просто IT отдел набирался смелости и начинал мигрировать часть сервисов. Причины тут не важны, тут интересны последствия: после миграции на виртуалки всё продолжало работать не хуже, чем до этого. Только вот оперировать этим становилось на порядок удобнее. Затем неизбежно вставал вопрос: Ок, виртуализация - это здорово и удобно, но как нам переехать обратно?. А обратно было уже не переехать. Во всяком случае не настолько просто, как при переходе на виртуалки. Да и сами люди уже не хотели возвращаться к старой модели, ибо новая на практике доказала свою эффективность и удобство.

И с облаками (особенно IaaS) сейчас происходит ровно тот же сценарий: мы их боимся > давайте потестируем и организуем облачную DR площадку > частично перевозим прод > оказывается, оно работает и это удобно > обратно вернуться сложно, да и не очень хочется, если честно. Всё это и привело к взрывному росту популярности. Даже в самой далёкой от IT компании если сейчас поднять вопрос о модной нынче цифровой трансформации, мало кто захочет заниматься закупками железа, планированием его размещения и ждать поставки полгода, если задачу можно решить созданием нескольких учёток в AWS/Azure, сидя дома на диване. Плюс многие компании сейчас воочию убедились в необходимости иметь под рукой возможность быстро масштабироваться в любую сторону. И быстрого - это значит здесь и сейчас, а не зависеть от поставщиков и прочих непредсказуемых факторов.

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

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

Первое, что приходит в голову - это сделать бекап машины изнутри, как было заведено ещё со времён больших железных серверов. Решение хорошее, но крайне далёкое от оптимального. Ведь в случае аварии у нас будет образ, для разворачивания которого надо первоначально развернуть машину, не ошибиться с её конфигурацией и надеяться, что со стороны облака не было изменений, из-за которых гостевая ОС не захочет стартовать на новой машине. Потом туда надо залить бекап и развернуть его. И хорошо бы по пути не разориться на платежах за трафик, IO и прочее. Как вариант, мы можем делать бекап только приложений, забирая дамп условной базы данных, но тут мы обрекаем себя на ещё большее количество увлекательных приключений при восстановлении. Да и интеграция всего этого в существующие процессы резервного копирования априори выглядит как нагромождение костылей.

Второй приходящий в голову сценарий - это посмотреть в сторону предлагаемых самим облаком решений. Тут есть два варианта развития событий. В первом варианте облачный провайдер строит своё облако на публичном коробочном решении - VMware Cloud, например. Плюс этого подхода в том, что для таких решений давно есть соответствующие продукты, которые будут работать с предсказуемым результатом. Тот же VMware Cloud - отличный пример таких интеграций, так как есть огромное количество клауд-провайдеров, где прямо заявляется о наличии услуги бекапов машин с помощью Veeam. В результате мы получаем знакомое решение, с понятным результатом и возможностями по интеграции. Звучит неплохо.

Другой вариант - это когда провайдер делает своё облако на закрытом решении. Причём отнесём сюда не только AWS, Azure и т.д., но и провайдеров, построивших своё облако на решениях, требующих тщательной доработки напильником под свои нужды, вроде OpenStack. Обычно такие провайдеры предлагают некие встроенные решения, однако при ближайшем рассмотрении они зачастую очень бедны по своему функционалу и накладывают массу ограничений на бекапируемые машины. Даже если посмотреть на AWS, то предлагаемое ими решение не будет претендовать на звание хотя бы хорошего из-за имеющихся ограничений. Например, бекапы автоматически складываются на S3 с последующим переездом в Glacier, без альтернативных путей. Здорово, конечно, но что делать если этот вариант не подходит? А что в это время будет происходить с приложениями внутри виртуалки и насколько они хорошо будут себя чувствовать после рестора? Тут вся проблема в том, что Amazon предлагает именно законченное решение, а не технический инструмент для выстраивания необходимого сервиса. Причина такого поведения проста: сделать и поддерживать гибкий инструмент в разы сложнее, чем законченное решение с парой опций, которое охватит потребности вероятного большинства клиентов. Профильная задача облачного провайдера - это поддержание функционирования облака, а всё остальное идёт по остаточному принципу. Так что инструмент для галочки есть, но решать свои задачи до конца мы им не можем. А про интеграцию с существующими решениями даже заикаться не будем. Её нет и не предвидится.

Так что в этом месте на сцену выскакивают 3rd party решения, использующие предоставляемые облаками API и старающиеся реализовать максимум гибкости в имеющихся условиях. Вроде наших Veeam Backup for Microsoft Azure, for AWS и прочих Office 365. Все они построены на стандартных API, однако позволяют реализовать логику резервного копирования, схожую с той, к которой вы привыкли до облаков, и, что самое важное: прозрачно интегрировать эти процессы в существующую инфраструктуру. Да, там есть свои чисто технические ограничения из-за предоставляемых вендором возможностей, однако с каждым релизом список доступных функций становится всё больше и больше.

И это чистая правда: если верить отзывам клиентов, то возможность интеграции облачных бекапов в общий пайплайн (назовём это так) вашего резервного копирования - это именно то, чего им так недостаёт в наше увлекательное облачное время. То есть раньше у нас весь выбор действий был ограничен возможностью бекапить машину из AWS в S3. И туда же её и восстановить. Получается классическое standalone-решение на минималках. А теперь рассмотрим облачный бекап в качестве равноценного участника всей инфраструктуры. Первым делом хочется скачать бекап из облака и положить его рядом с остальными. Причём скачать не просто в виде набора файлов, а чтобы наше бекапное приложение сохранило возможность полноценного оперирования им. Да, AWS даёт нам околобесплатный Glacier для долгосрочного хранения, однако ждать до нескольких дней для восстановления данных - это даже не смешно. Конечно, несколько дней - это максимальный срок, указанный в договоре, и скорее всего данные будут доступны раньше, но кто захочет добровольно попасть в то меньшинство, которое не скорее всего?

Но это пока не самое интересное. Как все мы понимаем, бекапы делаются не ради бекапов, а ради возможности восстановления. И будет странно ожидать от облачного провайдера возможности восстановить его виртуалки в вашу наземную инфраструктуру или, случись что, в другое облако. Однако мы эту возможность даём и позволяем восстанавливать ваши рабочие данные хоть в виде виртуалки в гипервизоре, хоть на обычный железный сервер, хоть перегонять машины из AWS в Azure. Про банальное желание восстановить отдельные файлы из машины или отдельные элементы приложений даже говорить не буду, так как это само собой разумеющийся функционал.

Следующий неочевидный нюанс: контроль расходов. Насколько точно вы сможете спрогнозировать размер счёта за создание и хранение бекапа на S3? Да, записать туда данные будет ничего не стоить, но каждая операция верификации записанных данных уже будет стоить денег. А что с созданием инкрементов, когда данные дописываются с оглядкой на уже хранящиеся (да-да, это снова масса платных операций чтения)? А сколько будет стоить удалить устаревшие точки? Словом, курочка по зёрнышку - и в конце месяца за казавшийся недорогим S3 вам может прийти крайне неприятный счёт. Поэтому при работе с облачными данными надо стараться чётко понимать, сколько будет стоить каждое ваше телодвижение и как можно сохранить максимальное количество денег. Мы в Veeam настолько преисполнились это темой, что разработали собственный калькулятор, позволяющий довольно неплохо предсказывать стоимость хранения ваших бекапов. Да, подобный сервис можно и самому организовать через калькулятор AWS, однако давайте прикинем, сколько надо учесть переменных: стоимость EBS снапшотов, стоимость самого S3 хранилища, стоимость работы воркера (машины, которая занимается созданием бекапов), не забываем про потребление трафика на случай использования разных регионов или желания скачать бекап, и помним про стоимость всех операций внутри S3. Так что не самое очевидное уравнение получается.

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

Помните, как во второй половине 90-х один известный тогда профессор хрипло пел Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Как и любое другое здравое современное приложение, Veeam Backup & Replication спроектирован таким образом, чтобы минимально загружать своему пользователю мозги и максимально эффективно справляться с поставленной задачей. На местах этот высокопарный посыл выражается в том, что независимо от масштаба вашей задачи устанавливается Veeam в три клика, ещё в пять делается первичная настройка и всё, полетели бекапы бекапироваться. Но как все мы отлично понимаем, это всего лишь радужная теория из мира с поняшками и бабочками. Ведь даже если самому приложению совершенно без разницы, бекапить ли ваш ноутбук на подключенный usb диск или гонять сотни терабайт снапшотов по FC фабрике (а ему действительно всё равно), то происходить это всё будет на вполне конкретном физическом железе, которому предстоит обработать все эти потоки данных. То есть, в то время, пока софтовая часть остаётся неизменной, архитектура решения в целом меняется до неузнаваемости.

Если скорость бекапа своего компа можно легко увеличить на порядок простой заменой USB 2.0 диска на USB 3.1, то имея задачу забекапить развесистую ферму серверов, да ещё и раскиданную по всему миру, можно столкнуться с тем, что в одном месте окажется слабый CPU, в другом процесс утыкается в объёмы доступной RAM, в третьем все ждут, когда контроллер дисковой полки соизволит записать очередную порцию данных, а в четвёртом так и вообще еле живой линк с внешним миром. Так что чем сложнее задача, тем проще и обиднее будет ошибиться с выбором любого из компонентов системы. И если за покупку слишком мощных серверов ругать вас не будут, то промашка в меньшую сторону скорее всего чревата большим числом неприятных разговоров в самом ближайшем будущем. Здесь - ты не поместился в бекапное окно, здесь - попытка сделать снепшот приводит к развалу кластера, а вот там просто нет ресурсов и придётся просить докупить новых железок. Так что тема планирования потребления CPU и RAM для бекапов не настолько и третьесортная задача, как к ней многие относятся.

Но прежде чем начать выписывать себе бюджеты на сотни CPU и тысячи гигабайт RAM, давайте освежим в памяти общую архитектуру Veeam Backup & Replication, чтобы точно не путаться в определениях и назначении компонентов.

1. Сам VBR (Veeam Backup & Replication) сервер. Командный центр, оркестратор, ЦУП, разум улья, словом, называйте как хотите, но основная его роль - это синхронизация всех остальных компонентов и выдача команд на запуск разных увлекательных внутренних процессов, отслеживание расписания, и так далее. Технически ничего не мешает разместить вообще все компоненты на одной машине, и они даже будут работать. Однако такой сервер и ресурсов потребует соответствующих, и производительность его будет далека от совершенства. Так что лучше размещать всё остальное согласно назначению. Об этом ниже.

2. База данных. Veeam - это классическое приложение, хранящее всю важную информацию в базе данных. Где и как вы расположите эту базу данных - его совершенно не волнует. Лишь бы до неё была связь и сервер стабильно работал. Хотите на одной машине с основной консолью? Пожалуйста! Для этого в установщике лежит Microsoft SQL Server 2016 SP2 Express Edition, который будет автоматически развёрнут и настроен самым лучшим образом. У вас уже есть своя инсталляция и вы хотите, чтобы база крутилась там? Без проблем! Просто укажите установщику адрес сервера и с какой учёткой туда идти. В процессе эксплуатации передумали и хотите перенести базу на другой сервер? Просто измените ключик в реестре или воспользуйтесь встроенной тулой. Всё для вас.

3. Прокси сервер или просто прокся. Не знаю, почему когда-то давно было решено назвать их именно так, но точно знаю, что новичков это название иногда путает (именно путает, а не пугает). Но не будем искать виноватых, а просто зафиксируем, что прокси - это тот компонент инфраструктуры, который будет читать данные с бекапируемого объёкта и укладывать их в бекап. Это если упрощенно, потому что на самом деле данные будут сжиматься, дедуплицироваться, шифроваться, на их пути могут возникнуть другие прокси, нестабильные каналы связи и всякие хитрые хранилища. Не суть. Сейчас важно зафиксировать, что прокси - это то, что примет на себя основной удар по обработке данных. Они запускают пары data movers, один из которых что-то откуда-то читает, а второй что-то куда-то пишет. Чуете очевидную мораль? Чем ближе ваша прокся к бекапируемому объекту и чем ближе к ней хранилище бекапов, тем быстрее будет идти процесс. Но тут важно не увлекаться и помнить, что чудес не бывает. Ваши машины лежат на FC сторадже? Так будьте любезны и проксе предоставить FC подключение, иначе как ей данные получать? Ну не через managed интерфейс хоста же, ну честное слово. Хотя на самом деле с этой проблемой связана одна из самых частых ошибок при конфигурации - пользователь хочет, чтобы бекапы работали через Virtual Appliance, а работает через Network. Но не будем сейчас о грустном.

4. Репозиторий. Он же бекапный сторадж. Может быть буквально чем угодно, к чему можно присоединиться, а ещё лучше, если там можно запустить наш дата мувер. Запустились на целевой системе - значит, можем контролировать процесс и часть операций проводить локально. Не можем запуститься на целевой системе - значит, приходится верить на слово, а каждый байт информации гонять взад-назад по сети. Так что во время любого синтетического трансформа бекапа, лежащего на сетевой шаре, ваша сеть будет вас ненавидеть. Поэтому Windows/Linux сервер - это твой бро, сетевые шары нет. Работать, конечно, будет, но медленно и не пойми как. Есть ещё целая россыпь вариантов вроде S3, дедуплицирующих систем и всяких специфических файловых систем вроде XFS, но это тема отдельного разговора. Просто помним, что репозиторий - это наше хранилище и гарант безопасного сна. Ну и особенно хорошо, если там можно запускать дата муверы.

5. Enterprise Manager. Командир над командирами, в котором можно объединить управление несколькими VBR серверами и дать рядовым пользователям пользоваться частью функций через простенький веб-интерфейс. Например, можно выдать гранулярные права своему хелпдеску на восстановление определённых объектов на определённых машинах. Удалил пользователь письмо и корзину почистил, а хелпдеск ему хлоп - и вытаскивает это письмо из бекапа. Красота.

6. И цифрой шесть давайте обозначим всё остальное, включая комбо-сервера, на которых крутится сразу по несколько ролей. Например, использовать один сервер в качестве и прокси, и репозитория - вполне нормальная идея, если серверу хватает ресурсов. Ну и помимо основных компонентов есть ещё целая россыпь вспомогательных: tape server, wan accelerator, cache repository и прочие gateway servers. Тут можно долго всё перечислять, тщательно объясняя, кто и зачем нужен, но мы здесь не за этим собрались. Лучше почитайте документацию, благо там всё очень понятно и подробно описано.

Главный посыл всего вышесказанного: VBR- это не одна конкретная машина, на которой вы прокликали мастер установки и получили работающее решение. Вернее, в небольших инсталляциях это, может, и так, но если у вас раскидистая инфраструктура, то VBR полностью готов ей соответствовать. Все эти компоненты и созданы, дабы дать возможность масштабироваться в зависимости от решаемой задачи. Странно будет поставить все компоненты VBR в европейском датацентре, если предстоит бекапить виртуалки по всему миру. Оставьте у себя в офисе управляющий сервер, а прокси и репозитории расположите рядом с машинами. Всё для вашего удобства.

С этим разобрались. Что дальше? Обычно всем сразу на ум приходит идея посчитать количество необходимого для хранения бекапов дискового пространства. Для этого принимается стратегическое решение: бекапить каждую машину раз в день и прикинуть, сколько же нам надо терабайт под бекапы - с помощью отличного калькулятора от Тимоти Девина.

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

1. Первым шагом будет проработка ваших RPO и RTO метрик, про которые уже было сказано очень много раз. Главное - запомнить основной посыл: не вы должны решать, с какой периодичностью делать бекапы и как быстро они должны восстанавливаться, а владельцы сервисов и те, кто называется на западе applications team. Вам надо собраться всех вместе и решить, для какого сервиса какой простой будет допустим и какой объём потерянных данных вы сможете пережить без того, что вас всех уволят, а компания закроется. Исходя из этого вы уже сможете построить вашу схему ротации бекапов, известную в англоязычной литературе как retention scheme.

2. После этого мы уже можем переходить к подсчётам необходимого места. И здесь не надо пытаться изобрести колесо: просто возьмите и посчитайте, сколько места сейчас занимает ваш продакшн.Да, реальный размер будет меньше за счёт дедупликации, компрессии и отбрасывания ненужных блоков, но это тот самый случай, когда никто вам не скажет как именно посчитать коэффициент сжатия (кроме эффективных маркетологов и продавцов). А запас, как мы знаем, карман не тянет.

3. Посчитали свои терабайты? Отлично, теперь считаем, сколько у нас виртуальных машин/серверов. Совсем хорошо будет, если получится посчитать количество дисков на них, так как несколько дисков параллельно обрабатывать можно, а вот один в несколько потоков не получится. Соответственно, два диска по 500Гб забекапятся быстрее, чем один на терабайт, при прочих равных.

4. Размер окна резервного копирования ака Backup window. Время, за которое должен состояться ваше бекап. Тут не всё так просто, как может показаться. Есть непосредственно бекап продакшена, который должен быть совершён вне времени основной офисной активности, чтобы не повлиять на сервисы. А есть некие побочные вещи, вроде бекап копи, синтетических трансформаций, записи бекапов на ленты и так далее. Если ваша инфраструктура резервного копирования находится на отдельном оборудовании и может спокойно заниматься своими делами, то вам повезло. Если нет, то ваша задача усложняется: надо, чтобы и сам бекап успел сделаться, и все последующие операции.

5. И завершает наш парад вводных самая спорная метрика: сколько новых данных в день будет появляться на ваших серверах. Daily change rate, как называют на западе. К сожалению, тут нет единственно верного ответа, как посчитать этот параметр. Кто-то ограничивается примерными значениями, кто-то делает снапшоты и через сутки смотрит на их размеры. Вариантов много, и точного на сто процентов нет. Но вполне можно обойтись и средней температурой по больнице: для машин без высокой активности считается, что в день изменяется не более 5% диска, а в среднем по больнице принято считать, что 10% изменяющихся данных в день - это отличный показатель для дальнейших расчётов.

У пунктов 2 и 5 есть тонкий момент. Как вы прекрасно понимаете, требуемые мощности для того, чтобы успешно и вовремя забекапить весь прод, несколько отличаются от мощностей, необходимых для создания инкрементов. Иногда на порядок. То есть покупать супер-мощный сервер под прокси, который будет только раз в год (а вдруг вам достаточно) упаковывать все ваши петабайты за ночь, а все оставшиеся дни просто греть воздух, может статься и не очень разумным. Возможно, проще будет купить сервер в два раза меньше, но выделять под бекап не четыре часа, а восемь. Или вообще разбить процесс на несколько дней, делая полный бекап только части машин. Словом, момент тонкий и требует отдельного осмысления.

Зато теперь, когда у нас наконец-то есть все вводные данные, можно смело вооружаться калькулятором и начинать считать. При подсчётах мы будем исходить из того, что следуем рекомендациям VBR, и количество параллельно обрабатываемых тасок равно количеству имеющихся у процессора ядер. А одна таска - это один обрабатываемый диск. То есть если у нас на прокси CPU с четырьмя ядрами, то одновременно будут обрабатываться четыре диска с бекапируемых машин. И каждая таска, согласно всё тем же рекомендациям, для спокойной работы требует 2 Гб RAM.

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

Итак, берём вводные: у меня 640 Тб данных, я хочу делать Per-VM бекап (потому что могу), на бекап у меня есть 8 часов ночью, а мой change rate - классические 10%.

Шаг первый: делим объём данных на имеющееся время и получаем некую скорость обработки данных, которой нам надо достичь. В моём случае получается (640 Тб* 1024*1024)/(8 часов * 60* 60) = 23075 Мб/с - такова должна быть пропускная способность нашей системы.

Шаг второй. Пусть жизнь наша нелегка, и всё, что у нас есть - это сервера, которые могут выдать только 100 Мб/с. Делим желаемое на имеющееся и получаем 23075\100= 230. Округляем в большую сторону до 231. Получилось количество необходимых ядер. Да, блюстители размерностей и единиц измерений могут прибывать в ужасе от таких переходов, но куда деваться. Для примера давайте ещё представим, что наши сервера не настолько древние и от гигабита пропускной способности в обморок не падают. Получится, что нам вполне хватит 24 ядра. Более чем посильное число для современного оборудования.

На третьем шаге умножаем количество ядер на рекомендованные 2 Гб на таск и получаем 24*2 = 48 Гб RAM. Да в ноутбуки уже больше ставят, если честно. А вот у коллеги с более старым железом получится 2312 = 462 Гб RAM. Уже более интересное число, но чего только не сделаешь, дабы успеть забекапиться вовремя.

Затем просто делим это цифры на желаемое количество проксей, округляем в большую сторону и получаем искомые параметры. Повторюсь, никто не запрещает вам использовать хоть десять прокси, хоть один. Просто выдавайте им соответствующие ресурсы, и всё будет здорово. У вас по 12 ядер в сервере? Отлично, 231/12 = 20 серверов по 24 Гб оперативки в каждом. И так далее.

И вспоминаем нюанс с инкрементами. Мы договорились принять, что у нас будет меняться по 10% данных в день. Подставляем в наши формулы: (640 Тб*0,1% * 1024*1024)/(8 часов * 60* 60)= 2 331 Мб/c / 100 Мб/c = 24 ядра * 2 Гб RAM на таск = 48 Гб RAM. Значит, при прочих равных для инкрементальных бекапов нам будем достаточно двух серверов, по 24 гига оперативки в каждом.

Вот и вся математика. Как видите, никакой магии тут нет и всё считается довольно просто. Да, в своих подсчётах мы используем некую общую пропускную способность в вакууме, а не берём конкретные цифры по скорости сети, дисковых полок и так далее, но кто кроме вас знает вашу инфраструктуру, её слабые и сильные стороны?

На этом предлагаю на сегодня закончить. Мы рассмотрели только самых основных потребителей ресурсов, но если вам хочется узнать подробности про каждый аспект (база данных, сам VBR, сколько ресурсов нужно для побочных процессов и так далее), то недавно мой коллега Tim Smith целый час рассказывал про это на своё вебинаре. Крайне рекомендую к просмотру всем интересующимся темой, так как там всё разобрано действительно до костей.

VTL (они же Virtual Tape Library, если по паспорту) можно назвать одним из самых странных порождений IT индустрии. Родившись в эпоху расцвета ленточных накопителей как классический софтовый эмулятор настоящего железа, многими они были восприняты как ответ на главный вопрос жизни (Вселенной и всего такого), и теперь одни умудряются продавать их за деньги, а другие использовать в проде и считать, что всё нормально.

Я не буду кричать что первые плохие, а вторых надо гнать из профессии. Нет. Я только лишь предлагаю трезво взглянуть на суть VTL.

А в чём проблема?

Чтобы разобраться с вопросом о легитимности использовании VTL, давайте вспомним, зачем вообще нужны ленты. Это самое дешёвое, не самое быстрое, зато физически отчуждаемое устройство для хранения информации. Про дешевизну можем говорить, если посчитаем цену условного терабайта хранения. Прямо сейчас LTO-8 лента в режиме сжатия способна принять на себя 30 Терабайт данных, при цене около 9000 рублей. Для объективности можно даже откинуть маркетологов с их сжатием и записать только честные, физически наносимые 12,8 Тб. Для сравнения, за те же деньги можно взять SSD на один терабайт или обычный HDD на четыре. А тут сразу 12,8. Или даже 30, если повезёт. Да, для ленты ещё нужен привод, а лучше даже библиотека с роботом ценой в несколько сотен тысяч рублей, но там, где есть приличные объёмы данных, для которых встаёт вопрос о хранении на протяжении многих лет, это всё-таки дешевле, чем закупать дисковые полки и заниматься их обслуживанием.

Но из-за своей природы (пластиковая лента с магнитным слоем) у лент есть несколько очень неприятных моментов. Например, на ленту можно не слишком быстро писать данные, а потом очень долго и медленно их считывать. Особенно если речь идёт о файлике, который физически оказался в самом конце вашей кассеты. Пока вы будете ждать перемотки ленты на необходимое место, тут даже HDD с его задержками на раскрутку шпинделя и необходимостью двигать коромысло со считывающей головкой покажется манной небесной. Другая ленточная беда - невозможность изменять файлы. Файл, записанный на ленту, можно только удалить. Изменили полтора байта в вашем файле? Добро пожаловать в конец дорожки, кажется, там ещё оставалось место, чтобы перезаписать весь файл ещё раз.

И, конечно же, помним про возможность простого физического отключения. Вставили ленту в привод, записали на неё что-то, привод ленту выдал обратно, вы её убрали подальше, и голова ваша не болит. Лента лежит, собирает пыль, и ничего с ней не происходит. Диски так не умеют. Даже если и хочется вынуть диск сервера и убрать на полку, то придётся разбирать корпус и вырубать весь сервер. Если это дисковая полка, то корпус разбирать не придётся, но насиловать не рассчитанные на постоянное туда-сюда разъёмы тоже не очень хочется. А вот лентам для счастья ничего не надо. Ни электричества, чтобы постоянно крутить шпиндель, ни страха перед разболтавшимися разъёмами.

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

Все эти прекрасные особенности давно заприметили разного рода регулирующие гос.органы примерно всех стран. Если вы не знали, то есть довольно много компаний, от которых на законодательном уровне требуется хранить разного рода информацию по многу лет. Спросите, например, медиков, банки, страховщиков и так далее. Вам могут рассказать массу увлекательных историй про то, как они вынуждены обеспечивать сохранность данных своих клиентов на протяжении лет десяти-пятнадцати. Вы же не думаете, что кто-то в здравом уме будет покупать дисковую полку, задача которой будет заключаться в простаивании 99% времени? Да и диски придётся поменять не один раз за эти десять лет. Поэтому не только зарегулированные, но и обычные компании, где решили заняться архивным хранением, давно пришли к выводу, что ленты и только ленты.

Но есть тут один нюанс, который объяснит нам причины появления VTL почти тридцать лет назад. Представьте, что ваше основное боевое хранилище это дорогущий SAN, сделанный с использованием самых последних технологий своего времени. И вдруг выясняется, что к этому FiberChanel монстру надо подключить ленточную библиотеку по страшному и медленному SCSI интерфейсу. Полученная скорость работы вызовет у вас депрессию, не извольте сомневаться. И вот, после недельного запоя у вас появляется светлая мысль: А может ну их, эти ленты?. Но потом вы вспоминаете, что это Ну их может стоить многих денег вашей компании в виде штрафов от регулятора. Ну и весёлых приключений лично вам, если звёзды сойдутся особенно удачно. Поэтому у вас рождается очень хитрый план: а давайте вместо лент мы будем использовать всё те же диски, а чтобы рисовать красивые отчёты, мы напишем эмулятор, который будет подключаться к нашему софту, отвечающему за резервные копии, и будет тщательно кивать головой на все его команды к лентам.

И на тот момент это сработало. Появились эмуляторы, функциональность которых находилась на уровне архиватора: упаковать файлы в свой формат и радостно отчитаться по SCSI (или любому другому) порту о том, что ленточка старательно записана, робот её вынул и даже положил вот в такой вот слот в своей библиотеке. Самое натуральное переливание из пустого в порожнее под флагом имитации бурной деятельности. Но дабы не только ругать VTL на чём свет стоит, стоит всё же упомянуть и про их плюсы. Самый главный, действительно, это всё ещё скорость. Если вам совсем некуда девать деньги и ваш VTL пишет свои файлы на SSD, то вы победитель по жизни. Но если с деньгами не настолько всё хорошо, а весь фронт работ это записать буквально десяток плёнок, то диски будут дешевле, как ни крути. Если не верите, то просто посмотрите, сколько стоят современные LTO приводы. Ну и вишенка на торте - нет необходимости перематывать кассету на нужное место. Читай сразу откуда хочешь.

Поэтому главное что хочется сказать - не обманитесь заманчивыми плюсами VTL. Буква V значит Virtual, а все преимущества(и недостатки) лент исходят из их физической природы. Так что VTL может принести вам только моральное удовлетворение, но никак не решить задачу недорогого хранения отчуждаемых бекапов на случай аварии. Да и смысл интеграции с бекапным софтом уже давно пропал из-за наличия встроенных функций для перекладывания бекапов из одной корзины в другую. Например, в Veeam эта функция называется Backup Copy. Пользуйтесь на здоровье.

Да, есть ещё так называемые D2D2T системы, где VTL используется в виде кеша, а потом готовые файлы просто записываются на ленты. Правда, сейчас их будет правильнее называть D2D2C, где C это Cloud.

Препарируем VTL

Ну ладно, раз VTL это идеальная лаба, чтобы ознакомиться с функционалом ленточного бекапа, давайте таки развернём эту лабу и попробуем записать наши бекапы на ленту, хоть и виртуальную. Я долго выбирал между более хардкорным MHvtl и QUADstor с его симпатичным GUI, но в итоге остановился на втором исключительно из-за большей его популярности. Хотя оба проекта бесплатные и обеспечивают плюс-минус одни и те же функции. А производить все манипуляции я буду на CentOS.

Первым делом, конечно же, yum update && yum upgrade и ставим все необходимые пакеты:

yum install httpd gcc perl sg3_utils kernel-devel

Наверняка большая часть этих пакетов и так уже стоит, но вдруг вы такой же маньяк и начинаете с CentOS minimal. Также рекомендуется проверить, что установленные версии ядра и тулзов совпадают, а то в наших планах QUADstor компилировать, и лишние проблемы нам ни к чему. Так что сравниваем выводы uname -r и rpm -qa | grep kernel-devel

[root@centos ~]# uname -r3.10.0-1160.15.2.el7.x86_64[root@centos ~]# rpm -qa | grep kernel-develkernel-devel-3.10.0-1160.15.2.el7.x86_64

Если у вас циферки разошлись, то спасаемся yum upgrade kernel и ребутом.

С подготовкой закончено, и мы можем полноценно переходить к установке подопытного. В стандартных репозиториях его нет, поэтому на помощь нам приходит wget и официальный сайт. На момент февраля 2021 у меня получилось вот так:

wget https://quadstor.com/vtldownloads/quadstor-vtl-ext-3.0.51-rhel.x86_64.rpm

Теперь идём в директорию, куда скачался файл (если она у вас не стандартная), и устанавливаем пакет. Внимание: я это делают в чисто лабораторных целях и условиях, поэтому поэтому могу себе позволить делать всё от рута. А вы нет! Делайте все с правами рядового пользователя.

rpm -ivh quadstor.rpm

На что я получил отлуп по зависимостям (ох уж эти CentOS minimal)

rpm -ivh quadstor.rpmerror: Failed dependencies:libcrypto.so.10()(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64libcrypto.so.10(libcrypto.so.10)(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64libssl.so.10()(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64

Ладно, мы не гордые, идём и ставим compat-openssl10, так как это всё его библиотеки. И повторяем установку, которая в этот раз завершается успехом за пару минут, и мы становимся обладателями QUADstor, mini PostgreSQL сервера, где будут храниться данные конфигурации, и небольшого Apache Web Server для Web-GUI. Хотя никто не запрещает и дальше всё делать через консоль, но мы пойдём по более наглядному пути. Только перед этим нам надо запустить веб сервер и проверить, запустился ли демон VTL.

systemctl enable httpdservice httpd start/etc/rc.d/init.d/quadstorvtl start

Также установщик вас предупредит, что если хочется работать по FC, то надо обязательно перезагрузиться для корректной установки драйверов. Но в наши планы входит исключительно iSCSI, так что храним аптайм. На этом с консолью действительно всё, и мы можем открывать в любимом браузере WebGUI по IP нашей машины.

Первым делом надо зайти в Physical Storage и выбрать диски для работы. По умолчанию QUADstor выбирает первый диск, который обнаруживает. Читай, диск с системой. У меня на скриншоте виден второй диск, подключённый к этой виртуалке, так что смело выбираю его кнопкой Add.

Сразу предложат добавить этот диск в один из Storage Poolов, которые надо создать заранее. Это некая логическая единица для смыслового объединения лент по какому-то признаку. Как видите, ничего супер-необычного здесь нет, весь джентльменский набор: дедупликация для экономии места, WORM кассеты и репликация кассет. Но нам сейчас это всё не так интересно, поэтому ограничимся стандартным пулом.

Но самое интересное находится в секции Virtual Libraries. Здесь мы выбираем, хозяина какой именно железки мы будем из себя изображать. А то и нескольких сразу, ведь кто нам запретит? Так уж сложилось, что душой я за HP, поэтому хотел выбрать себе HP MSL 6000 с двумя приводами Ultrium 6250, но потом передумал и для наглядности выбрал ветерана ленточных боев - ESL 9000.

И теперь самое время закупитьнарисовать себе кассет побольше. Хотя совсем уж много не получится, ибо ленты хоть и виртуальные, но информация хранится на совершенно реальных нерезиновых дисках. Но вся прелесть VTL в том, что в любой момент можно всё отредактировать как надо и не думать о проблемах с железом.

На этом с настройкой VTL всё, и хочется перейти в интерфейс Veeam, дабы скрестить его с библиотекой. Однако мы не ищем лёгких путёй и подключим библиотеку к другой Windows машине, которая будет работать у нас в качестве Tape Server. Для чего заходим на этот сервер, запускаем iSCSI сервис и iSCSI инициатор. Там находим нашу библиотеку любым из доступных способов и подключаемся к ней. По умолчанию будет использоваться порт 3260, так что может потребоваться добавить соответствующее правило на вашем фаерволе.

Тут наступает важный момент: надо обязательно открыть Device Manager и посмотреть как определились новые устройства. Крайне рекомендуется поставить драйвера, чтобы избежать проблем при работе с библиотекой. Veeam использует стандартные системные вызовы, поэтому если система может работать с библиотекой, Veeam тоже будет работать. А нет драйверов - нет мультиков. Так что если у вас старьё вроде того, что я добавил в свою лабу, система сама всё поставит. Если что-то новое, то качайте с сайта производителя. Технически, Veeam может работать и с универсальным Microsoft Tape Format (MTF), но оригинальные драйвера всегда в приоритете.

И теперь (наконец-то) можно идти на сервер Veeam и открывать вкладку Tape Infrastructure. Где первым делом запустим мастер добавления Tape Server.

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

Если всё было сделано правильно, то Veeam начнёт бодро двигать туда-сюда кассеты, проверяя и внося их в свой стандартный медиа пул.

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

Но мы отвлеклись, так что давайте вернёмся в Veeam и проверим, что всё добавилось верно.

Как мы видим на скриншоте, библиотека определилась верная, приводы на месте, а количество кассет совпадает с заданным. Все кассеты находятся в медиа пуле Free, так как мы провели инвентаризацию. Если её пропустить, то все неизвестные ленты попадут в пул Unrecognized. Можно принимать поздравления, ибо всё действительно работает как и должно.

Давайте же тогда посмотрим, как бекапы находят своё пристанище в недрах ленточных приводов! На самом деле про это уже были исчерпывающие посты от моих коллег. Вот этот и вот тот. Поэтому я здесь пробегусь по самым верхам, дабы не переписывать уже написанное.

Итак, запускаем мастер Backup to Tape, задаём имя джобе и на втором шаге добавляем бекап, который хотим хранить на ленте. Технически можно добавить не просто бекап, а хоть целый репозиторий с бекапами, но мы такого делать не будем. Просто берём один красивый бекапчик.

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

Про медиа пулы, опять же, отсылаю вас читать документацию и статьи коллег, а для наших целей отлично подойдёт согласиться на все предлагаемое по умолчанию и добавить все имеющиеся кассеты. Главное, не забудьте на шаге Options выбрать использование сразу нескольких приводов. Можно ограничиться и одним, но зачем это делать, если мы создали два?

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

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

Ну а почему бы и нет? Имею право на мечты! Разве не для этого были придуманы VTL решения?

И на последок, ловите ссылку на раздел документации посвящённый работе с ленточными девайсами. Скорее всего там вы найдёте ответы на все свои вопросы.

Функция CDP (она же Continuous Data Protection) для многих сейчас видится манной небесной. Ведь она позволяет свести риски потери данных к около-нулевым значениям (RTO и RPO - единицы секунд), при этом не используя тормозящие всё вокруг себя снапшоты, и не зависеть от ограничений классических вариантов репликации.

Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.

Achtung! Прочтение данной статьи никак не освобождает вас от необходимости изучить официальную документацию. Написанное ниже следует понимать скорее как выжимку из ключевых моментов с дополнениями, нежели как более правильную или альтернативную версию документации. И пока далеко не ушли, очень советую особенно тщательно изучить раздел Requirements and Limitations. Ещё никогда он не был настолько важен, как в случае с CDP. Почему-то именно здесь у многих появилось какое-то очень своё видение этой технологии, что мешает трезво оценивать её реальные возможности. Особенно часто все любят упускать слово Clusters. Может в это весна виновата, но суть одна: нет кластеров - нет мультиков. Совсем.

Зачем CDP нужен этому миру

Начинаем по порядку: а какие проблемы может решить CDP и кому он нужен?

Отвечать будем по порядку поступления вопросов, чтобы ответ на предыдущий помогал понять ответ на следующий. Итак, CDP - это ещё один вид репликации виртуальных машин. Вот так всё просто. На этом всё. Всем спасибо, все свободны. Шутка.

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

Соответственно, проблема, которую помогает нам решить CDP - это обеспечение минимальных значений RTO и RPO. Получается, что это история для самых важных приложений, где допустимый простой может измеряться минутами или даже секундами. А лучше, чтобы его вообще не было. Разные умные люди считают, что под эти требования попадает не более 5% нагрузок. Просто от их функционирования зависят остальные 95%, так что обеспечение их бесперебойной работы становится основной задачей IT отдела.

Хорошо, но чем тогда нас не устраивают классические реплики? В том же Hyper-V, технически, можно реализовать репликацию каждые пять секунд. Вот же оно! Но нет. Вся проблема в снапшотах и задержках, которые они тянут за собой. Как ни крути, но создание снапшота - это весьма небанальный процесс (просто посмотрите на эту обзорную схему работы VSS), происходящий сначала на уровне машины, а потом и хоста. Который неизбежно приводит к задержкам и накладным расходам. А потом снапшот надо удалить, а в процессе всех этих операций не угробить машину и работающие на ней приложения (что очень запросто, уж поверьте). Да и в целом, весь этот процесс выглядит довольно громоздко: надо создавать пачку снапшотов (на уровне ОС, потом на уровне гипервизора, а потом ещё и на уровне датасторы может понадобиться), выхватить пачку получившихся данных (не просто прочитать файлик, а получить его в виде дельты двух состояний), куда-то их все махом переложить, корректно удалить снапшоты в обратном порядке и дать отмашку гостевой ОС, что можно продолжать спокойно работать.

Так что если снапшоты можно исключить, их надо исключить.

Как работает CDP

Видя всё это безобразие, разработчики из VMware как-то сели крепко подумать и решили выпустить некое API, которое сейчас известно под именем VAIO. Фактически, это технология, позволяющая сделать классический I/O фильтр, который даёт возможность следить за I/O потоками гостевых машин и делать что-то с этим знанием. Причём с момента включения этого фильтра ни один изменившейся на диске байт не останется без нашего внимания. А дальше дело за малым: берём эти блоки, копируем из одной машину в другую - и мы восхитительны. Буквально пара недель работы программистов, неделька на тестирование, и можно релизить.

Хотелось бы так, но нет. На практике всё несколько сложнее. Давайте разбираться.

Вот так выглядит общая схема работы. Для видавшего виды VBR пользователя здесь знакомо только слово Proxy. И, пожалуй, да, на прокси вся схожесть с классическими схемами работы и заканчивается.

Погнали по списку:

• Координатор. Умывальников начальник и мочалок командир. Управляет всеми процессами, отвечает за связь с vCenter, говорит другим компонентам, что делать, и всячески следит, чтобы всё было хорошо. На местах выглядит как Windows сервис. Единственный, кто знает про существование таких вещей, как vCenter и виртуальные машины. Все остальные работают только с дисками. Поэтому всё, что не связано с репликацией контента, делает координатор. Например, создаёт виртуалку на таргете, к которой мы прицепим реплицируемые диски.

• Source filter. Та самая штука, которая занимается перехватом IO запросов. Соответственно, работает уже на ESXi. Дабы повысить надёжность и производительность, один инстанс фильтра работает с одним виртуальным диском. Фильтры держат связь с демоном.

  Технически, фильтр - это dll библиотека, живущая внутри виртуальной машины. И если с ним что-то случается (залипла память, скрешился и т.п.), то следом прилетает виртуалке, внутри которой он работает. Поэтому жизнеспособности фильтров было уделено огромное внимание. Ну и если вы сомневаетесь по поводу прямоты рук создателей фильтра: такие штуки можно устанавливать на хосты только после прохождения строгой сертификации получившегося изделия со стороны VMware.

Важно: VBR производит установку на кластер. Довести фильтр до каждого хоста - это уже задача самой VMware. Причём если вы добавляете новую ноду в кластер, то наш бандл на него будет установлен автоматически. Зачем? Давайте представим, что произойдёт, если в кластере появится новая нода и для какой-то из машин сработает vMotion на эту ноду? Всё верно - CDP реплика сломается. Однако вся эта автоматика не отменяет необходимости пройти через Manage I/O filters визард - для актуализации настроек. Поэтому, если добавили ноду, то быстренько проходим Manage I/O filters визард, который обнаружит новичка и всё настроит.

• Source Daemon. Используется один на каждый хост. В отличие от мифического фильтра, который где-то там работает, демон - это вполне конкретный процесс на хосте. Отвечает за связь с координатором и общается с прокси на предмет поиска оптимального маршрута трафика. Работает по медленному TCP, так как шустрый UDP не гарантирует доставку. И да, это именно тот случай, где это критично и необходимо.

  Зачем нужна прокладка в виде демона и почему бы фильтру самому не работать с прокси? Это ограничение технологии со стороны VMware, не позволяющее фильтру работать с внешней сетью. То есть фильтр с демоном связь установить может, а с прокси нет. Это называется by design, и ничего с этим не поделаешь. Во всяком случае, сейчас. И напомню: демон не знает ни про какие виртуальные машины. Он работает с потоками данных от дисков. И ничего другого в его мире не существует. Поэтому диски одной машины могут обрабатываться сразу несколькими прокси. Мы, конечно, стараемся отвозить диски одной машины через один прокси, но если она не справляется, то подключится другая. И это нормально!

• Source Proxy. Агрегирует в себе всю информацию, полученную от фильтров через демонов. Хранит всё строго в RAM, с возможностью подключения дискового кэша, если оперативка кончилась. По этому очень (ОЧЕНЬ!) требователен к RAM, дисковому кешу и задержкам на сети. Так что только SSD и прочее адекватное железо.

  Прокси занимается составлением так называемых микроснапшотов, которые отправляются дальше. Данные перед передачей обязательно дедуплицируются: если в каком-то секторе произошло 100500 перезаписей, то до прокси дойдут все, но с самого прокси будет отправлена только одна последняя. Так же, само собой, всё сжимается и шифруется.На местах прокси представляют собой Windows машины, которые могут взаимозаменять друг друга, переключать нагрузку и так далее.

• Target Proxy. Всё то же самое, но в обратном порядке. Принимает трафик от сорсных проксей, расшифровывает, разжимает, отправляет дальше. Так же может быть как физический, так и виртуальный.

• Target Daemon. Занимается записью данных на датастор. Полная копия сорсного демона.

• Target Filter. В нормальном состоянии находится в выключенном виде. Начинает работать только во время фейловера и фейлбека, но об этом позже.

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

Немного промежуточных деталей

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

Как мы видим, процессы, связанные с CDP, довольно плотно интегрированы в сам хост. Так что при выполнении многих операций надо быть предельно внимательным. Например, апгрейд/удаление VAIO драйвера происходит строго через maintenance mode. Установка, что хорошо, такого не требует. На случай отсутствия DRS предусмотрена защита, которая не даст запуститься процессу, однако это же IT, и бывает тут всякое. Поэтому действовать надо осторожно и внимательно.

И ловите бонус: фильтр с хоста можно удалить командой:

esxcli software remove -n=veecdp.

Но есть проблема: как я писал выше, установкой фильтров на хост занимается VMware в автоматическом режиме, поэтому при выходе из mm фильтр появится снова. Так что правильно удалять фильтр через кластер. Наименее зубодробительный способ - это через powercli:

Get-VAIOFilter |Remove-VAIOFilter

И дальше по обстановке.

Мой любимчик - DNS. Должен работать как часы, по принципу каждый-каждого, ибо все мы знаем, что Its always DNS. Если у вас на VBR сервере используется один DNS сервер, а в vCenter и на хостах другой, то в этом нет никакой проблемы до тех пор, пока они могут резолвить неймспейсы друг друга. То есть vCenter должен уметь зарезолвить VBR и хосты. А хосты должны уметь резолвить VBR и vCener. И так далее.

И, конечно же, не забудем обрадовать ненавистников разного рода устанавливаемых на гостевую ОС агентов и сервисов. Для CDP ничего такого делать не надо, и даже админские креды никому больше не нужны (если только вы готовы отказаться от VSS точек с application consistent состоянием). Наконец-то угнетатели повержены и можно спать спокойно. Всё работает исключительно за счёт магии VAIO API.

Retention

Самое время упомянуть альфу и омегу запросов в саппорт - ретенш. А между прочим, их тут сразу целых два!Вот это поворот! (с)

На длинной дистанции мы используем Long-term retention, гарантирующий консистентность на уровне приложений(application aware). Делается это с помощью VSS и требует предоставления админской учётки от гостевой ОС. Выглядит это как создание точек отката с определённой периодичностью (например, раз в 12 часов), которые хранятся несколько дней.

И второе - это Short-term Retention, где гранулярность отката может доходить до 2 (двух!) секунд, но гарантируется только crash-consistent восстановление. Для short-term указывается значение RPO - как часто сохранять состояние дисков - и сколь долго хранить эти изменения. Можно понимать это как количество времени, которое мы будем хранить наши RPO точки. На скриншоте ниже мы будем хранить данные с нарезкой по 15 секунд за последние 4 часа.

Расписание, само собой, гибко настраивается, позволяя, например, обеспечивать crash-consistent только в офисное время, а в ночное переключаться на редкие, но application-consistent точки.

Если подходить глобально, то вариантов сделать фейловер у нас два: прямо сейчас по кнопке Failover now или создав Failover Plan. Соответственно, если случилась авария, то мы можем сделать фейловер нашей реплики в следующих режимах:

• Откат на последнее состояние (crash-consistent)

• Восстановиться на нужный нам момент времени в режиме Point-in-time (crash-consistent)

• Откатиться на Long term точку (здесь можно выбрать между application-aware и crash-consistent)

А failback и permanent failover делаются по правилам обычных старомодных реплик, так что останавливаться на этом не буду. Всё есть в документации.

Совет: в выборе нужного момента времени при Point-in-time ресторе очень удобно двигать ползунок стрелочками на клавиатуре ;)

Как работает CDP ретеншн

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

• .VMDK Тут без сюрпризов. Обычный диск вашей машины, который создаётся в момент первого запуска репликации.

• .TLOG и .META - логи и метаданные транзакций. Всё для того, чтобы ничего не потерялось. Также они позволяют сделать откат на произвольный момент времени.

• VM-000X.VMDK Дельта диски, коих может быть огромное количество. И не думайте, что каждый дельта диск - это точка отката. Это просто хранилища блоков данных, жестко связанные с файлами логов транзакций. Примерно как в базах данных. Когда вы будете делать фейловер, Veeam выстроит цепочку из нужных дельта дисков и первоначального VMDK. А с помощью лога транзакций найдёт необходимые блоки данных, которые фильтр применит к базовому диску при запуске машины. Это тот единственный момент, когда нам нужно включить Target Filter.

Short-term retention

Теперь рассмотрим, как это работает.

• В первый момент времени на таргете нет ничего, поэтому, чтобы начать работать, нам надо взять и в лоб поблочно скопировать VMDK файл с сорса на таргет.

Интересный факт: в интерфейсе VBR иконки успешно переехавших машин окрашиваются в синий. В то время как их менее успешные товарищи остаются серыми. Если время, которое вы выделили на первичную синхронизацию, уже прошло, а машины так и не посинели, то надо разбираться, что им мешает. Правильный и простой вариант действий в этом случае: обратиться в сапорт. Более долгий и увлекательный - копаться в логах самому. Только учтите, что на тему CDP логов можно ещё одну статью смело писать, так что лучше доверьте это дело профессионалам.

Совет: если тащить по сети огромный VMDK вам нет никакого удовольствия, то Seeding и Mapping вам в помощь. Они позволяют перевести ваши файлы на таргетный хост хоть на флешке в кармане, в дальнейшем подключив их к заданию.

Абсолютно реальна ситуация, при которой на реплицируемой машине в момент первой синхронизации будет настолько большая нагрузка, что таргет будет не успевать записывать все приходящие блоки (оригинальный диск + новые блоки). Особенно если там используется сторадж значительно медленнее сорсного. Поэтому когда накапливается большое количество блоков, для которых не было получено подтверждение о доставке, сеть останавливается, и не надо этого бояться. Как только придёт достаточное количество подтверждений, сеть запускается заново. А подтверждение - это когда таргетный демон рапортует об успешной записи всего микроснапшота (про это чуть ниже) на сторадж. Ситуация не слишком частая, но бывает и такое.

Возникает закономерный вопрос: каков размер этих самых блоков? Он динамический и зависит от размера диска. Для простоты можно считать, что 1 Тб диска соответствует 1 Мб блока.

• Как только VMDK перевезён, можно начинать создавать дельта диски. Для чего фильтр и демон начинают отслеживать IO машины, отправляя по сети всё, что пишется на машине.

• Этот поток сознания, приходя на сорс прокси, проходит через процедуру отбрасывания лишних блоков. То есть если некий блок за период репликации был перезаписан несколько раз, то в дельту уйдёт исключительно последнее его состояние, а не вообще все. Это позволяет сохранять вагон ресурсов и два вагона пропускной способности вашей сети.

• Рядом с дельта диском создаётся транзакцонный лог.

• Если лог становится слишком большим, то создаётся новый дельта диск.

• И так всё работает до достижения выбранного Retention policy. После чего Veeam смотрит на содержимое лога.

• Если это просто устаревшая точка восстановления, которая нам больше не нужна, то данные из неё вносятся в наш базовый диск, и файлы удаляются.

• Если оказывается, что в логе нет вообще ничего, необходимого для создания новых точек восстановления, такой файл сразу удаляется.

Примечание: Соблюдение Retention Policy довольно важно. Однако поддержка CDP реплики в боевом состоянии ещё важнее. Поэтому в механизм заложена потенциальная возможность временного расширения периода хранения до 125% от первоначального.

Long-term retention

Служит логическим продолжением short-term retention. То есть всё работает ровно так, как и написано выше, пока не наступает момент создать long-term точку.

• В этот момент создаётся особый дельта диск. Внешне он не отличается от других, однако во внутренней логике он помечается как long-term delta.

• Репликация продолжает идти своим чередом.

• Когда подходит время для срабатывания short term, то все предыдущие логи и дельта диски (если их несколько) просто удаляются.

• Теперь всё считается от этой long-term точки. Она остаётся нетронутой и высится как глыба.

• Затем создаётся новая long-term точка, и цикл замыкается.

• Когда подходит время, то самая первая long-term точка инжектируется в базовый VMDK.

Про логику транзакций

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

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

Отсюда два важных следствия:

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

• На втором участке задержка уже не критична. Если даже в какой-то момент времени мы не успеваем получить подтверждение от таргетного демона, то данные остаются в кеше сорсного и таргетного прокси и будут переданы ещё раз. Если кажется, что такое кеширование избыточно, то это кажется. Сети сейчас, конечно, быстрые, но зачем лишний раз лезть далеко, если можно попросить данные ближе? В логе джобы в этот момент возникнет предупреждение, что RPO нарушено, но ничего критичного ещё не случилось. Позднее данные будут довезены до таргета.

Что под капотом у фильтров

Теперь, когда мы разобрались на базовом уровне в устройстве и принципах работы CDP, давайте посмотрим более внимательно на работу отдельных компонентов. А именно фильтров. Ведь именно от их красивой работы зависит всё остальное. И как мы все прекрасно понимаем, ровно и красиво может быть только в лабораторных условиях. Именно там у нас всегда стабильный поток IO операций, нет резких всплесков нагрузки, сетевые пакеты никуда не пропадают, и все графики выглядят как прямая рельса, уходящая за горизонт.

Именно из-за таких расхождений с реальностью у фильтров есть два режима работы. Clean Mode и Dirty Mode. В первом варианте у нас всё хорошо, и все измененные блоки мы успеваем отправить вовремя, а на принимающей стороне успевают их принять и уложить в требуемое место. Но как только над нами сгущаются тучи и мы не успеваем передать очередную порцию данных, CDP фильтр переключается во второй режим. Вернее, он получает команду от демона, что у того переполнена очередь на отправку и новые данные хранить негде. После чего фильтр перестаёт передавать данные, а только ведёт учёт изменённых блоков. Такие блоки данных помечаются как DirtyBlockMap. Единственное, что можно сделать в этой ситуации - это ждать возвращения стабильного канала связи и отмашки, что всё успешно записалось на таргет. Как только принимается решение, что связь удовлетворяет нашим потребностям, помеченные блоки передаются ещё раз, и в случае успеха фильтр переключается обратно в Clean Mode.

Немного сухих цифр: кэш каждого из фильтров - на всё про всё 32 МБ. Вроде мало, но больше и не надо. Задача фильтра - считать блок и как можно быстрее поставить в очередь сорс демона. Там кэш - уже 2 ГБ заранее выделенного RAM. Дисковый кеш прокси задаётся пользователем вручную. И в целом надо помнить, что архитектура CDP подразумевает максимальное наполнение кеша всех из компонентов в надежде, что данные всё же получится отвезти на таргет. И только когда кончается вся свободная память, реплика останавливается с ошибкой.

Вот так вот можно изобразить на любимых всеми квадратиках с буквами режимы работы. В данном примере у нас установлено RPO 10 секунд, из которых пять секунд (половина RPO) мы отслеживаем изменения данных, а вторую половину времени пытаемся передать последнее их состояние. То есть, промежуточные, как я говорил выше, нас не интересуют.

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

Примечание: Чтобы администратор спал спокойней, предусмотрены два оповещения, скрывающихся под кнопкой RPO Reporting. Фактически они просто считают, сколько данных за указанный промежуток времени мы можем потерять. И бьют в набат, если что-то пошло не так.

Инфраструктура

Обычно, когда заходит речь о проработке какой-либо инфраструктуры, все сразу начинают думать про CPU и RAM. Но только не в этот раз! Здесь надо начинать с поиска вашего сетевика, чтобы он сделал вам сеть с наикратчайшим маршрутом, с 10 Gbit+ линками, и не забыл включить MTU 9000 (Release Jumbo frames!!!) на всём протяжении маршрута. Согласно нашим тестам, такой набор нехитрых действий позволяет добиться прироста производительности почти на 25%. Неплохо, да?

Но не бросаем сетевика на полдороге и тащим его к тем, кто занимается серверами: для VMkernel должны стоять выделенные физичеcкие NIC. Если нет - не приходите жаловаться на тормоза. Ибо сеть, скорее всего, будет забита под потолок своих возможностей. Но вообще, чисто технически, минимально нужны гигабитные карточки и задержки в пределах 80 мс.

Теперь сетевика можно уже отпустить и переключиться, например, на таргетный сторадж. Тут всё очень просто: всегда используйте выделенный сторадж. Процесс записи невозможно как-то замедлить, попросить подождать пока идёт транзакция от другого приложения, и так далее. Нет, сторадж будет молотить на весь свой ценник и вряд ли будет очень рад дополнительным нагрузкам. Хотя, конечно, тут всё зависит от вашего железа. Ну и роли прокси, конечно же, лучше выдавать выделенным машинам. Насчёт того, физическим или виртуальным - тут мнения расходятся. Лично я за физические, но правильно будет протестировать на месте.

И общий совет на все случаи жизни: десять маленьких CDP политик всегда будут работать лучше и стабильней, чем одна большая. Что такое маленькая политика? Это до 50 машин или 200 дисков. В мире большого энтерпрайза это считается за немного. Технически, опять же, здесь ограничений нет, и проводились успешные тесты аж до 1500 машин и 5000 дисков. Так что лучше, опять же, протестировать на месте и найти оптимальный для себя вариант.

Немного о прокси

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

Что хочется сказать про этих ребят:

• Дисковый кеш - это исключительно запасной план на случай закончившейся оперативки. Всё придумано и сделано так, будто находится исключительно в RAM. Поэтому, пожалуйста, не жадничайте и дайте серверам памяти.

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

• В идеальном мире на один ESXi - один прокси.

• А вот физический или виртуальный на том же хосте - этого вам никто не скажет, и надо тестировать. Часто бывает, что виртуальный оказывается быстрее физического.

• Да и вообще, общая логика такова, что чем больше вы сможете развернуть прокси серверов, тем лучше будет результат. Особенно если речь идёт о репликации между удалёнными дата центрами.

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

Давайте разбираться что же это такое и откуда оно взялось. Все эти скорости и количества являются ничем иным, как усреднёнными максимумами за последний час, полученными от vCenter. То есть это не мы что-то там померили в моменте, ловко запустив какие-то таинственные тесты, а такова родная статистика хостов за последний час.

Давайте теперь пройдёмся по строчкам.

Source Proxy CPU: количество ядер CPU на всех доступных проксях, которые могут работать в качестве сорса. Видим vCPU, но читаем как ядра CPU.

Source Proxy RAM. Здесь уже посложней будет. Цифра перед скобками показывает, сколько оперативки нам может понадобиться для данной CDP политики.

Формула расчёта довольно простая: RPO* пропускную способность.

Пропускную способность кого/чего? Да всех дисков всех вируталок, участвующих в этой политике. Напоминаю, что берётся максимальное значение за последний час.

То есть предположим, что наш RPO - 15 секунд, и что диски выдают 150 Мб/сек. Значит, нам понадобится 2250 Мб RAM.

А цифра в скобках - это вся доступная оперативка на всех наших проксях, Но, как обычно, есть нюансы. Во-первых, половина RAM считается зарезервированной под нужды ОС и других приложений. Это можно подправить ключиком в реестре в любую сторону (сие остаётся полностью на вашей совести). Во-вторых, учтите, что в случае возникновения задержек на сети или задумчивости хранилища, данные будут сохраняться в кеше до двух минут, после чего будет включена аварийная сирена. И если в течение этих двух минут память переполнится, то подключится медленный дисковый кэш.

Source Proxy Bandwidth. Здесь опять всё просто. Число перед скобками мы получаем от vCenter, а число в скобках считается на основе доступного количества ядер с округлением до целого. Если мы шифруем трафик, то это 150 Мб/с на ядро. Если не шифруем, то 200 Мб/с на ядро.

Target Proxy CPU. Всё ровно так же, как у сорса: взяли и посчитали все доступные ядра на доступных проксях.

Target Proxy RAM. Хочется, как и в предыдущем пункте, сказать, что всё такое же, но нет. Здесь в формулу для расчёта внесён поправочный коэффициент 0.5. А значит, что если мы за те же 15 секунд хотим обработать 150 Мб/c от дисков, то понадобится нам уже только 1125 RAM (вместо 2250, как это было с сорсом).

Target Proxy Bandwith. Здесь тоже не обошлось без скидок. Считаем, что одно ядро при шифровании трафика будет обрабатывать 350 Мб/c, а без шифрования - все 400 Мб/c.

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

Быстрое Ч.А.В.О. в конце

Как добавить в CDP Policy выключенную машину?

Никак. Виртуалка выключена > фильтр не работает > передавать нечего.

Какие версии vSphere поддерживаются?

Ну я же просил - читайте документацию, там всё есть. Но пользуйтесь пока я добрый: 6.5, 6.7, 7.0

Хочу минимальное RPO, чтобы ну вообще ничего не потерялось.

Если у вас железо хорошее (прям хорошее-хорошее, а не вам кажется, что хорошее), то вполне реально добиться RPO в 2 секунды. А так, в среднем по больнице, вполне реально обеспечивать 10-15 секунд.

А что с vRDM?

Всё отлично поддерживается.

А можно CDP прокси назначить и другие роли?

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

А можно CDP реплику, как и обычную, использовать для создания бекапов?

Нет. Во всяком случае сейчас.

Я могу запустить CDP реплику из консоли vCenter?

Нет. С точки зрения vCenter там какой-то фарш из дельта дисков, поэтому он выдаст ошибку зависимостей.

А если я руками удалю CDP реплику из Inventory в vCenter?

Умрут все id и всё сломается. А вы чего ожидали?

А если таргетная стора будет чем-то очень загружена?

Veeam будет присылать на почту уведомления, что очень старается, но у вас ботлнек на принимающей стороне и нельзя впихнуть невпихуемое.

А что с Hyper-V?

Это вопрос к Microsoft.

Немного полезных ESXi команд

Убить daemon сервис:

# ps | grep iof# kill -9 <PID>

Остановить/запустить daemon сервис:

# /etc/init.d/iofilterd-vvr stop/start

Полюбопытствовать насчет последних логов демона:

# tail -n 100 -f /var/log/iofilterd-vvr.log

Выяснить, сколько памяти потребили все демоны:

# vsish -e get /sched/memClients/[iofilterd-PID]/SchedGroupID

# memstats -r group-stats -s name:min:max:eMin:rMinPeak:consumed:flags -g [iofilterd-ScheddGroupID] -u mb

Проверить установку пакета фильтра. Он выглядит как обычный vib

# esxcli software vib list | grep veecdp

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

В то же время умение работать с логами - очень ценный и полезный навык. Я бы сравнил работу с логами с поеданием овсянки. Есть овсянку - полезно == уметь анализировать логи - полезно. Ну, а для того, чтобы овсянка стала вкуснее, в нее я добавлю топпинг - интересный сценарий. Чем более загадочной выглядит проблема, тем интереснее становится анализ логов, и ты смотришь уже не просто на строки текста, а распутываешь клубок из улик и доказательств, проверяешь или опровергаешь теории.

Ну что, наливаем чаек, сейчас мы будем расследовать - Детектив с Кластером Hyper-V

Дисклеймер: я привожу пример того, как я анализирую логи. Жесткого стандарта нет, и действия других инженеров техподдержки Veeam могут (и будут) отличаться. Скриншоты и логи взяты из моей лабы, так как логи клиентов никогда не публикуются и удаляются при закрытии кейса.

0. По традиции - все начиналось с ошибки.

Как и в любом детективе, начало весьма обычное: есть конкретная проблема. В этом случае выглядела она как тикет от клиента с примерно таким содержанием:"Помогите! Задание падает с ошибкой - Processing FS2 Error: Failed to get VM (ID: 6fb62d8a-4612-4106-a8e7-8030de27119e) config path. [WMI] Empty result."

Когда есть конкретная ошибка, это уже хорошо. Сразу понятно: что-то явно сломано это как стук в двигателе машины. Мы видим, что это ошибка в работе Backup job - задании резервного копирования для нескольких виртуальных машин. В этой ошибке даже есть аббревиатура [WMI], а это уже зацепка!

Как говорит википедия: WMI это одна из базовых технологий для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows.А я бы сказал: WMI - это технология, используя которую Veeam B&R отправляет запросы на Hyper-V хост или кластер. Это могут быть такие запросы, как создание чекпоинта, удаление чекпоинта, создание коллекции, добавление VM в коллекцию и так далее.

Зная это, мы понимаем, что имеем дело с Hyper-V инфраструктурой. (Далее надо будет понять, кластер это или же одна нода). А проблема связана с WMI запросом, который вернул пустое значение. (Empty result)

Промежуточный вывод: задание резервного копирования для пяти виртуальных машин на гипервизоре Hyper-V завершилось успешно для трех машин, а для двух выдало ошибку - Failed to get VM (ID: 6fb62d8a-4612-4106-a8e7-8030de27119e) config path. [WMI] Empty result.

1. Приступаем к сбору логов

С чего же начинается анализ логов? - В первую очередь со сбора этих самых логов! В некоторых случаях собрать правильные логи - это уже полдела! Напоминаю, мы расследуем конкретное задание (Job), и портфель с логами нам нужен именно для этого задания.

Дело в том, что в задании помимо Veeam сервера задействованы другие компоненты. Это и Hyper-V ноды, на которых крутятся машины из задания, и репозиторий, на который пишутся файлы бэкапа, и прочие прокси. В общем случае таких серверов может быть достаточно много.И что же теперь? Нам лазать по всем серверам и копировать файлы? Нет, в нашей ситуации процесс сбора логов - полуавтоматический, благо в VBR есть встроенный помощник для таких дел. Есть даже статья с анимацией - https://www.veeam.com/kb1832 Поэтому, в консоли Veeam переходим в Menu -> Help -> Support information

При выборе опции (Export logs for this job), Veeam B&R соберет файлы со всех компонентов (прокси = Hyper-V ноды), вовлеченных в задание. Также будет добавлен HTML отчет, который может очень сильно упростить анализ. Одним словом - песня, все логи в одном архиве, да ещё и отчетик прилагается.

2. Анализ собранной информации

Итак, распаковали архив и видим следующее:

• Папка с логами, собранными с Veeam B&R сервера - storepc.dom1.loc

• Папки с логами, собранными с двух Hyper-V нод - 19node1 и 19node2

• Отчет по конкретному заданию - Critical FServers.html

Хммм, с чего же начать..

А начинать, я считаю, надо от общего к частному. Общим в нашем случае будет HTML отчет - так как в нем мы видим общую информацию о выполнении задания за период времени, и можно прикинуть статистику. Ну и, конечно же, отчет более приятен человеческому глазу, чем сотни строк логов =)

2.1 Отчет задания, и зачем его смотреть

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

Что же мы видим в отчете?

1. Сервер FS4 падает с ошибкой;

2. Через несколько минут - успешный Retry для сервера FS4

3. Во время следующего штатного выполнения задания серверы FS2 и FS3 падают с этой же WMI-ошибкой

4. Через несколько минут - успешный Retry для серверов FS2 и FS3

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

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

Теории о том, что:

• есть проблемная машина или ряд проблемных машин;

• есть проблемная Hyper-V нода ;

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

2.2 Логи задания: ищем стэк ошибки

Так как ошибка одна, но появляется для разных машин, то мы просто выбираем любое выполнение задания с ошибкой и анализируем его. Для начала идем в лог, который описывает обработку конкретной машины в задании - той, для которой вышла ошибка. Схема, по которой ищутся логи для задания - Veeam сервер\Backup\Название задания. В нашем случае это storepc.dom1.loc\Backup\Critical_FServers. Более подробно про структуру логов и где что лежит мы писали в отдельных статьях здесь и здесь.

В этой папке для задания резервного копирования можно встретить 3 типа логов:

1. Agent - логи компонента, который занимается передачей данных (Veeam Agent - Data mover). Если в названии есть слово Target, значит - это лог агента, который записывал данные на репозиторий. Если это задание репликации, то Target будет в папке на сервере, который использовался в качестве целевого прокси и писал данные на хранилище данных гипервизора (Datastore) куда реплицируем. Если в названии есть слово Source, значит - это лог агента, который читал данные с хранилища данных гипервизора (Datastore).

2. Job - это лог задания целиком. При общении с сапортом можно смело говорить просто джоба, и вас поймут.

3. Task - это лог подзадания (таски), из которого состоит задание (Job). Каждая виртуальная машина в задании обрабатывается отдельной таской, которая пишет свой отдельный лог.

Мы открываем файл, начинающийся с Task и содержащий название VM. В нем просто ищем ошибку. Обычно нажимаем CTRL+End - это перебрасывает нас в самый низ лога, и потом крутим колесико вверх, пока не увидим нужную нам ошибку.

[29.09.2020 08:04:21] <38> Info     [WmiProxy:19node1] HviGetVmConfigPath: <InputArguments><Hvi_LogName value="Critical_FServers\HvWmiProxy-STOREPC-19node1.log" /><Hvi_Host value="STOREPC-19node1" /><Hvi_Process value="00002870" /><Hvi_RequestId value="000000000000002d" /><Hvi_TimeoutMs value="3600000" /><VmId value="3564c574-8a83-42d2-aef4-46e7218d8ccc" /></InputArguments>[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 17[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 16[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 15[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 14[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 13[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 12[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 11[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 10[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 9[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 8[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 7[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 6[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 5[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 4[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 3[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 2[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 1[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CVeeamHvIntegrator} object [02ca5f28]: Counter = 1[29.09.2020 08:04:21] <42> Error    Failed to get VM (ID: 3564c574-8a83-42d2-aef4-46e7218d8ccc) config path. [WMI] Empty result. (Veeam.Backup.ProxyProvider.CHvWmiProxyErrorException)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiReconnectableRemoteCommand.InvokeInThread(Delegate dlg, Object[] args)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiReconnectableRemoteCommand.DoInvoke(CHvWmiProxyRequestContextNdw context, Int32 reconnectsCount, Delegate dlg, Object[] args)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiReconnectableRemoteCommand.Invoke[Ret](CHvWmiProxyRequestContextNdw context, Func`1 dlg)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiVmRemoteManager2015.GetConfigPath(Guid vmID)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.Core.HyperV.CHvVmSource2015..ctor(IVmBackupTask task, CBackupTaskSession taskSession, CBackup backup, CSmbLookupCache smbLookupCache, CHvSnapshotHolder snapshotHolder, CHvVssConnectionCreatorSet vssConnCreatorSet, IStopSessionSync sessionControl)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.Core.HyperV.CHvBackupJobPerformer.CreateSource(CHvVmTask task, CBackupTaskSession taskSess)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.Core.HyperV.CHvBackupJobPerformer.ExecuteTask(CHvVmTask task)

Стэк выглядит вот так, и нам он говорит, что был WMI запрос HviGetVmConfigPath: - этот запрос попытался получить путь до конфигурации VM по ID и в ответ получил пустой результат. Круто! Запрос! А дальше-то что?

А дальше нужно смотреть логи компонента, отвечающего за запросы, анализировать их, чтобы наконец построить теорию.

2.3 Логи WMI запросов на Hyper-V ноду с сервера Veeam

Нам нужны логи Veeam компонента, который отправляет WMI запросы на Hyper-V ноде.

Подсказка: его мы видим в стеке с ошибкой который я показал выше :

Host value="STOREPC-19node1"LogName value="Critical_FServers\HvWmiProxy-STOREPC-19node1.log

Идем в папку, собранную с интересующей нас Hyper-V ноды 19node1

И находим лог компонента, отвечающего за WMI запросы - HvWmiProxy. Ошибиться сложно, поскольку файл начинается с HvWmiProxy и заканчивается либо названием ноды, либо кластера (когда запросы отправляются в кластер). В нашем случае это название ноды - HvWmiProxy-STOREPC-19node1.log

Здесь мы находим уже весь запрос:SELECT Name, ElementName, __RELPATH FROM Msvm_ComputerSystem WHERE Name = "6fb62d8a-4612-4106-a8e7-8030de27119e"

И тут мы можем видеть, что он вернул пустой результат (Empty result). А что вообще он должен возвращать-то? Вопрос хороший, давайте посмотрим, как отработал успешный запрос для другой машины.

[29.09.2020 08:08:53.995] <  7748> hwp| HviGetVmConfigPath[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_CommitedRequestId__ARRAY = { 00001f0000000012, 00001f0000000011, 00001f0000000010 }[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_DevelopMode = True[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_Host = STOREPC-19node1[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_LogName = Critical_FServers\HvWmiProxy-STOREPC-19node1.log[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_Process = 00002440[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_RequestId = 00001f0000000013[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_TimeoutMs = 3600000[29.09.2020 08:08:53.995] <  7748> hwp|   VmId = da624636-429f-4bc9-b15e-a3de0bc77222[29.09.2020 08:08:53.995] <  7748> hwp| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[29.09.2020 08:08:53.995] <  7748> hwp| Getting VM (ID: da624636-429f-4bc9-b15e-a3de0bc77222) config path.[29.09.2020 08:08:53.995] <  7748> hwp| Executing wmi query 'SELECT Name, ElementName, __RELPATH FROM Msvm_ComputerSystem WHERE Name = "da624636-429f-4bc9-b15e-a3de0bc77222"'.[29.09.2020 08:08:54.003] <  7748> hwp| Executing wmi query 'associators of {Msvm_ComputerSystem.CreationClassName="Msvm_ComputerSystem",Name="DA624636-429F-4BC9-B15E-A3DE0BC77222"} where resultClass = Msvm_VirtualSystemSettingData'.[29.09.2020 08:08:54.179] <  7748> hwp| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[29.09.2020 08:08:54.179] <  7748> hwp| Result[29.09.2020 08:08:54.179] <  7748> hwp|   Hvi_RequestId = 00001f0000000013[29.09.2020 08:08:54.179] <  7748> hwp|   Hvi_State = Succeeded[29.09.2020 08:08:54.179] <  7748> hwp|   VmConfigFile = Virtual Machines\DA624636-429F-4BC9-B15E-A3DE0BC77222.VMCX[29.09.2020 08:08:54.179] <  7748> hwp|   VmConfigFolder = C:\ClusterStorage\Volume1\FSes\FS1[29.09.2020 08:08:54.179] <  7748> hwp| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[29.09.2020 08:08:54.179] <  7748> hwp| Duration: 0.184000 sec[29.09.2020 08:08:54.193] <  7912> hwp| ---------------------------------------------------------------------------

Видим, что результатом запроса был конфигурационный файл виртуальной машины. Возникает вопрос: почему же для одной машины файл был успешно найден, а для другой нет? Мы знаем, что через несколько минут на ретрае проблемная машина была все же обработана. Идем анализировать ретрай. (смотрим лог подзадания Task):

[29.09.2020 08:06:41] <23> Info     [WmiProxy:19node2] HviGetVmInfo: <InputArguments><Hvi_CommitedRequestId__ARRAY><value Val="0000000000000004" /></Hvi_CommitedRequestId__ARRAY><Hvi_LogName value="Critical_FServers\HvWmiProxy-STOREPC-19node2.log" /><Hvi_Host value="STOREPC-19node2" /><Hvi_Process value="00001d98" /><Hvi_RequestId value="0000000000000005" /><Hvi_TimeoutMs value="3600000" /><VmId value="3564c574-8a83-42d2-aef4-46e7218d8ccc" /></InputArguments>

Мы видим, что в этот раз запрос на получение конфигурационного файла машины уже шёл через другую Hyper-V ноду 19node2. Открываем лог HvWmiProxy со второй Hyper-V ноды и видим, что там WMI запрос отработал успешно.

Здесь я предлагаю сделать перерыв, не торопиться читать дальше, а попытаться самому построить теорию. Ведь в детективах самое интересное - это не просто дочитать до конца, а пытаться разгадать еще в середине, а потом просто проверить свои догадки.

2.4 Промежуточные итоги и наконец - теория!

Подводим промежуточные итоги анализа:

• Запрос валится с пустым значением, когда выполняется на одной Hyper-V ноде, и через несколько минут отрабатывает корректно, когда выполняется на другой Hyper-V ноде.

Напрашивается резонный вопрос почему на ретрае запрос стал выполняться на второй Hyper-V ноде? Как Veeam определяет, какая нода должна обрабатывать машину? Для обработки машины (создание снапшота и тд.) Veeam выбирает ту ноду, на которой находится машина (owner). В один момент времени у машины может быть только один владелец (owner). Получается, что в момент штатного выполнения машина числилась на одной ноде, а в момент ретрая уже на другой.

А такое вообще возможно?

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

Эту теорию о миграции надо проверять.

2.5 Проверка теории

Идем смотреть лог самого задания, он же Job лог. Там находим таблицу, в которой прописан список Tasks (подзаданий) для каждой машины:

[29.09.2020 08:03:16] <01> Info     Valid vm tasks ('5'):[29.09.2020 08:03:16] <01> Info     =================================================================================================================[29.09.2020 08:03:16] <01> Info     VM                   | Clust. |  Host                     | Size        | Provisioned |  Snapshot Mode| Off-host proxies                                  [29.09.2020 08:03:16] <01> Info     =================================================================================================================[29.09.2020 08:03:16] <01> Info     FS1                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS2                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS3                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS4                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS5                  | yes    |  19node2                  | 1024 MB     | 4 MB        |        enCrash|     

В таблице ясно виднона какой ноде находилась VM во время начала задания. Здесь мы видим, что FS4 была на первой ноде. Смотрим таблицу во время ретрая:

Lifehack: переключаться между выполнениями задания в логе (и штатными, и ретраями) очень удобно, нажав CTRL+f (поиск) и искать new log. Таким образом будешь скакать от выполнения к выполнению - только не забудь указать, куда хочешь мотать, вперед или назад.

[29.09.2020 08:06:45] <01> Info     Valid vm tasks ('1'):[29.09.2020 08:06:45] <01> Info     =================================================================================================================[29.09.2020 08:06:45] <01> Info     VM                   | Clust. |  Host                     | Size        | Provisioned |  Snapshot Mode| Off-host proxies                                  [29.09.2020 08:06:45] <01> Info     =================================================================================================================[29.09.2020 08:06:45] <01> Info     FS4                  | yes    |  19node2                  | 1024 MB     | 4 MB        |        enCrash|   

Вуа-ля! Мы подтвердили, что машина мигрировала (смена ноды для машины и есть миграция).В случае необходимости можно запросить и глянуть Windows Events с ноды. Нужные события находятся в ветке Hyper-V-VMMS > Admin.

Элементарно, Ватсон!

Следовательно, такую, казалось бы, мистическую ситуацию можно объяснить достаточно просто во время начала задания Veeam строит список машин, которые нужно будет обработать, и определяет на какой Hyper-V ноде какая машина находится. Когда дело доходит до машины, то обрабатывается именно та Hyper-V нода, на которой она была в момент начала задания.

В ситуации, когда в задании много машин, и некоторые ждут своей очереди несколько часов, вполне реальна ситуация, что машина мигрирует на другую ноду, и возникнет такая ошибка. На ретрае Veeam опять определяет Hyper-V ноду для машины, и все отрабатывает штатно. Это одна из причин, почему десять мелких бекапных заданий будут лучше, чем одно большое.

Возникает законный вопрос почему бы не определять Hyper-V ноду для машины прямо перед началом её обработки, чтобы учесть возможность миграции? Дело в том, что такие ограничения связаны с шаренными снапшотами и оптимизациями для параллельной обработки виртуальных машин.

Шаренный снапшот - это когда создается теневая копия на уровне хоста, и в неё добавляются сразу несколько компонентов Hyper-V VSS райтера. Это необходимо, чтобы сделать одну теневую копию волюма, и с этой копии сделать бэкап нескольких виртуальных машин, расположенных на нем. В противном случае для каждой виртуальной машины будет создаваться заново теневая копия всего волюма, на котором расположено несколько машин.

Эти настройки описаны здесь - https://helpcenter.veeam.com/docs/backup/hyperv/backup_job_advanced_hv_hv.html?ver=100

Подробнее о том, зачем используется теневая копия (VSS) во время бэкапа, можно почитать здесь - https://helpcenter.veeam.com/docs/backup/hyperv/online_backup.html?ver=100#2012r2

А сама опция называется - Allow processing of multiple VMs with a single volume snapshot

Таким образом, Veeam в самом начале задания анализирует все виртуальные машины, которые предстоит бэкапить, и в зависимости от разных факторов (например, расположение на одном волюме) может выбирать машины группами. Соответственно, ресурсы планируются в самом начале выполнения задания. И то, что машина мигрировала - это нештатная ситуация, которая успешно отрабатывается на повторе. Поэтому можно сказать, что возникновение такой ошибки - это ожидаемая и подконтрольная ситуация, как бы странно это ни звучало.

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

Автор: Никита Шашков (Veeam), Customer Support Engineer.

Снятие снапшота - именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux).

Но сегодня речь пойдёт про самую распространённую ОС - Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.

А, собственно, что с ним за проблема? Вот есть документация, где вполне адекватно и красиво описано, как всё работает. Есть утилита vssadmin, позволяющая вполне годно создавать и удалять снапшоты. Что не так-то, и где сложности?

Но проблема в том, что более лучшая документация, намного правильнее отражающая происходящие процессы, несколько сложна для понимания. Microsoft вообще написал по этой теме какое-то неслыханное количество документов. Но даже когда вам как-то удаётся выстроить в голове работу этого алгоритма, вы сразу сталкиваетесь с тем, что на практике многие вещи работают совершенно не так, как описаны. Или вообще не работают. А что-то не описано совсем, хотя этому мы уже давно не удивляемся. Но не хвататься же сразу за дебагер и дизассемблер, да?

Хотя упомянутый выше vssadmin как-то вроде и работает, и снапшоты даже делает, и вообще молодец. Но это всё до того момента, пока ты не начинаешь вникать в тонкости, где может выясниться, что репорт об успешно созданном снапшоте - это репорт о чём угодно, только не об успешно созданном снапшоте.

Вот поэтому и захотелось немного поговорить о том, как же на самом деле работает VSS. И да, строго говоря, результатом работы VSS является созданная shadow copy. Но дабы не ломать язык и не мучить вас транслитом, давайте просто писать снапшот.

Какова роль VSS

Не сомневаюсь, что 90% читающих прекрасно понимают, зачем нужны снапшоты, но ради оставшихся 10% потерпите несколько предложений. Или сразу идите в следующий раздел.

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

Сами снапшоты ничего не знают про ваши файлы и папки. Они работают на уровень ниже файловой системы - с блочными устройствами и блоками данных. Если придерживаться терминологи Microsoft, то снапшот - это место, именуемое Shadow Storage, куда записываются изменённые блоки данных и откуда их можно извлекать с целью переписать данные на оригинальном диске. Тут можно запомнить для себя два нюанса. Первый - только что сделанный спапшот занимает ровно ноль байт. Это просто пре-алоцированное место, куда файловая система может копировать измененные блоки (или наоборот, новые блоки, но не суть). И второй - теневая копия суть есть дифференциальный бекап. Все данные, которые вы изменили, не удаляются, а отправляются на хранение в этой зоне.

Где найти VSS

Обнаружить следы VSS можно двумя классическими способами: через GUI или в консоли. В зависимости от конкретной версии системы пути могут немного отличаться, но суть будет одинакова. Итак, есть у меня в лабе Windows Server 2019, и если сделать ПКМ на любом диске в проводнике, мы увидим два пункта: Configure Shadow Copies и Restore previous versions.

Если зайти в мастер настроек, то можно включить создание теневых копий для любого диска, задать расписание, по которому они будут создаваться и, что самое интересное, указать место хранения этих копий. Строго говоря, даже не самих копий, а так называемой diff area - места, куда сбрасываются перезаписанные на оригинальном томе сектора. То есть мы запускаем создание снапшота одного диска, а его данные физически храним на другом. Функция архиполезная и позволяет не просто снижать нагрузку на конкретном диске, но и делать фокусы а-ля снимаем снапшот одной ноды в кластере и цепляем его к другой.

После того,как вы всё настроите на свой вкус, появляется смысл в пункте Restore previous versions. Чисто технически туда и до этого можно было зайти, однако внутри, скорее всего, будет только гнетущая пустота.

Но всё это баловство с графическим интерфейсом, и как мы знаем, до добра это не доводит, поэтому открываем powershell (или даже cmd, почему нет) - и там у нас имеется два варианта из коробки: vssadmin и diskshadow. Первая утилита есть практически на любой системе, начиная с WinXP/Win2003. Нет её только на Windows 8. По какой-то таинственной причине из восьмёрки вырезали инструменты управления теневыми копиями, но потом осознали свою неправоту и вернули всё на место. А вот diskshadow доступен только на серверных вариантах Windows. Это уже более продвинутый вариант vssadmin, позволяющий работать не только в интерактивном режиме, но и выполнять целые скрипты, написанные на понятном этому интерпретатору языке. Да и просто это более адекватный и поддающийся контролю инструмент.

И запоминаем самое важное: это две разные утилиты, существующие в разных контекстах. Теневая копия, сделанная в одной утилите, будет видна другой, однако статус у неё будет неоперабельный.

Технически ничего не мешает одновременно делать снимки с помощью vssadmin и diskshadow. Хотя есть вероятность, что получите сообщение типа Another shadow copy is in progress. Но это так, к слову пришлось. Не надо пытаться одновременно делать несколько снапшотов разными программами.

Как появился VSS

Итак, судя по написанному выше, всё просто: нам надо просто брать появляющиеся блоки и сохранять их куда-то в сторонку, чтобы при необходимости вынимать обратно. Сразу возникает первый вопрос: а что именно надо сохранять в нашем теневом хранилище? Ведь действительно, можно просто писать в него все приходящие новые блоки и сохранять в метаданные, на какое место они (блоки) должны были быть записаны. А можно поступить чуть сложнее и записывать новые блоки сразу на полагающееся им место, а в хранилище отправлять содержимое перезаписываемых блоков. Что лучше и как выбрать? На самом деле право на жизнь имеют оба варианта, и какой выбрать - зависит исключительно от воли вендора. Первый подход (redirect-on-write, RoW, если оперировать грамотными терминами) быстро пишется, но долго читается. Зато если надо откатиться на первоначальное состояние, это делается моментально - мы просто удаляем наше теневое хранилище. Второй подход (copy-on-write, CoW) пишется медленней, читается быстрее и моментально удаляет копии предыдущих состояний. VSS, к слову, придерживается парадигмы CoW, а в снапшотах VMware реализован RoW.

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

Давайте рассмотрим хрестоматийную ситуацию с файлом базы данных. (И если у вас уже заскрипел песок на зубах, смело пропускайте следующие два абзаца.) Итак: у нас есть банальная SQL Server база данных в виде mdf файла, и тут к нам прилетает какой-то запрос. SQL, как порядочное приложение, начинает старательно вносить изменения в файл, а мы старательно перехватываем каждый новый блок данных падающих на диск и пишем в нашу теневую копию. Всё хорошо и здорово, но тут выключили свет. Потом свет включили, сервер запустили и мы даже базу восстановили из нашей теневой копии, но тут оказывается, что SQL не запускается. Говорит - база в не консистентном состоянии. Это значит следующее: во время нормальной работы завершение каждой транзакции помечается специальным флагом. Сервер его видит и знает, что всё хорошо. А тут сервер загружается, видит, что из его базы торчит какой-то кусок данных, флага нет и, следовательно, что с этим всем делать - он понятия не имеет. То ли удалить, то ли дописать, то ли ещё что-то. Но у нас тут не угадайка, а всё должно быть однозначно и консистентно. Поэтому он принимает решение выключиться, дабы не поломать базу ещё сильнее.

Хорошо, но как избежать подобных приключений? Отличным вариантом будет подождать, пока SQL сервер допишет свою транзакцию, пометит её как завершённую, и потом мы быстренько заберём все появившиеся новые блоки. Отличный вариант, который надо срочно реализовывать! Вот только есть небольшая проблема: до этого мы говорили про одно приложение и один файл, с которым оно работает. Научиться общаться с условным SQL Server много ума не надо, но что делать с остальными миллиардами существующих приложений? А что делать, в конце концов, с самой ОС, у которой внутри огромное количество своих процессов и открытых файлов? Вот примерно с такими проблемами и столкнулись учёные мужи из Microsoft, когда пришли к выводу, что надо реализовать некий общий интерфейс, через который можно будет сразу всем прокричать нечто вроде: Сейчас мы будем делать снапшот, так что быстренько сворачиваемся и сбрасываем буфера на диск! Приостанавливайте свою кипучую деятельность и приводите данные в консистентный вид!. Ну а назвать эту штуку они решили, как вы уже догадались, Volume Snapshot Service. Или просто VSS.

И тут можно воскликнуть - но ведь в Windows 2008 был представлен Kernel Transaction Manager! Это разве не то же самое? Он же как раз занимается тем, что приводит файлы на диске в консистентное состояние. А вот и нет! То есть да, KTM приводит, но отвечает только за дисковые операции, а что там происходит с приложениями - его мало волнует. А ведь многим из этих приложений важна не просто целостность файлов, но и что в них записано. Классический пример - это Exchange и Active Directory. И тут мы подошли к важной теме:

Как устроен VSS

Чтобы не прыгать с места в карьер громады страшных терминов и процессов, начнём с высокоуровневого описания. Поэтому ограничимся таким списком компонентов:

• VSS Writer. В кириллическом простонародье известен как просто райтер, поэтому так и будем его называть в дальнейшем, вызывая праведный гнев ненавистников англицизмов.

  Райтер занимается тем, что выстраивает мостик взаимодействия между VSS подсистемой и конкретным приложением. Поэтому а) в любой системе их будет достаточно много (проверьте у себя с помощью vssadmin list writers) б) райтер всегда пишется поставщиком приложения, ибо кроме него никто не знает, что там и как должно происходить во время создания снапшота.

  Соответственно, райтер по своей сути выполняет роль регулировщика: сначала он говорит приложению подготовиться к снапшоту, затем даёт отмашку VSS сервису делать снапшот. Или не даёт, если приложение не смогло за установленный промежуток времени подготовить свои файлы.

  Также хочется отметить, что райтеры - это какие-то невероятно нежные ребята, которые зачастую ломаются без каких-либо внешних признаков. Поэтому если в выводе vssadmin list writers в поле State вы увидите что-то, отличающееся от Stable, это надо чинить, ибо сделать консистентный бекап, увы, не получится.

• VSS Provider. Тот самый парень, который занимается созданием и управлением снапшотами. Известен тем, что бывает софтовый или хардовый. Список установленных в системе провайдеров можно посмотреть с помощью команды vssadmin lisrt providers. По дефолту, с системой идет Microsoft Software Shadow Copy provider. Он даже отлично и замечательно работает, но до тех пор, пока вы не подключите к системе брендовую СХД. Хорошие вендоры всегда снабжают свои железки управляющим софтом, в составе которого находится и родной провайдер к этой железяке. Благодаря этому можно уже делать всякие хитрые трюки, которые реализованы в вашем оборудовании, и именно поэтому мы в Veeam так гордимся списком интеграций с железом.

• VSS Requestor. Участник процесса, который инициирует создание VSS снапшота или восстановление данных. Можно сказать, что реквестор - это бекапное приложение, которое общается с райтерами и провайдерами. Может показаться, что его роль незначительна, однако от грамотности реализации реквестора зависит качество получаемого результата. То есть VSS не будет за вас думать, что и в каком виде надо сделать. Чем более чёткие инструкции выдаст реквестор, тем более предсказуемым будет результат.

Как в итоге всё выглядит на самом высоком уровне: реквестор стучится в Volume Shadow Copy сервис, тот отдаёт команду райтерам предупредить приложения о надвигающемся снапшоте, райтеры рапортуют об успехе, а сервис отдаёт команду провайдерам делать снапшоты. О результатах докладывается реквестору.

Но на деле, очевидно, всё несколько сложнее. На первом шаге реквестор проверяет, что вообще есть в наличии и с кем предстоит общаться. Затем после составления списка райтеров он обращается к провайдеру, объясняя, что он хочет заснапшотить и где должен располагаться снапшот. Это называется SnapshotSet. В большинстве случаев он будет располагаться на том же вольюме, что и оригинальный диск. А меньшинство случаев - это те самые хардварные провайдеры, которые поставляются вместе с СХД. Для них нормой считается создавать отдельный вольюм для снапшота, который называется storage snapshot. А в определённых случаях можно так и вообще перемещать снапшот на другое физическое устройство, чтобы выкачивать данные уже оттуда, а не с прода. Без хардварных провайдеров сделать такое не выйдет.

Следом начинается стадия, именуемая Prepare for backup. На этом этапе мы должны уже не просто изучить метаданные райтеров, а запросить их реальные статусы и приготовиться к самой жаркой поре: все райтеры должы будут отработать один за другим. Причём каждый должен уложиться в отведённое ему время, которое по умолчанию равно 60 секундам. Так решили в Microsoft, забыв уточнить причины. Но есть ещё приложения-чемпионы, например, Exchange. Его авторы посчитали, что 20 секунд более чем достаточно, и остановились на таком лимите. А чем чревато невыполнение этого этапа, который в документации называется OnFreeze? Тем, что райтер вернёт сообщение об ошибке, и снапшот не будет сделан. После чего в интерфейсе Veeam появится одна из каноничных ошибок вроде VSSControl: Failed to freeze guest, wait timeout". Тут радует одно: в логах VSS всегда будет написано, какой именно райтер завалил задание. А по самим ошибкам уже столько KB написано, что вспоминать страшно. Но если вы вдруг сомневаетесь, то точно вам говорю - написанному в них можно смело верить. И если после всего получается, что у вас слишком медленное хранилище, и за отведённое время не получается сбросить все кэши на диск, ну, значит, так оно и есть. Физику не обманешь, а вот железо надо хоть иногда обновлять.

Но это был пессимистичный вариант (прошу понять меня правильно, но беды с VSS - это очень частная причина обращений в сапорт), а в оптимистичном можно начинать самый важный этап. Как только райтеры рапортуют, что всё, вся деятельность в системе заморожена, а кеши сброшены на диск, у нас есть десять(!!!) секунд на создание снапшота, после чего райтеры будут принудительно разморожены, и всё закрутится вновь. И можно сказать, что на этом процесс бекапа заканчивается, и всё что нужно - это просто импортировать наш снапшот и скачать его куда-то к себе, чтобы сохранить под семью замками. Однако есть одно важное Но - log truncate. Фундаментально это вообще не связанные операции и транкейт зависит только от бекапа логов, но как все мы понимаем - на пользовательском уровне эти вещи связаны в единый процесс. То есть, прежде чем выкачивать снапшот, надо не забыть выдать команду backup log, которая запустит операцию транкейта. И после этого совесть наша чиста.

Но что дальше происходит с данными? Если мы действительно используем какое-то приложение для бекапов, которое запустило весь этот процесс, дождалось его завершения и скачало данные в своё хранилище, то снимок можно просто удалить одной командой. Поскольку VSS пропагандирует CoW подход, то речь здесь действительно о банальном удалении нашей аллоцированной зоны, ведь все новые данные сразу пишутся на оригинальный диск. Это называется non-persistent shadow copy, и она не имеет никакого смысла без оригинального диска.

Чтобы пройти этот путь вручную, достаточно открыть консоль и набрать:

PS C:\Windows\system32> diskshadowMicrosoft DiskShadow version 1.0Copyright (C) 2013 Microsoft CorporationOn computer:  VEEAM,  17.05.2021 19:18:44DISKSHADOW> add volume c: # добавляем в задание диск СDISKSHADOW> create# создаём снапшотAlias VSS_SHADOW_1 for shadow ID {a1eef71e-247e-4580-99bc-ee62c42221d6} set as environment variable.Alias VSS_SHADOW_SET for shadow set ID {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c} set as environment variable.Querying all shadow copies with the shadow copy set ID {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c}        * Shadow copy ID = {a1eef71e-247e-4580-99bc-ee62c42221d6}               %VSS_SHADOW_1%                - Shadow copy set: {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c}       %VSS_SHADOW_SET%                - Original count of shadow copies = 1                - Original volume name: \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ [C:\]                - Creation time: 17.05.2021 19:19:45                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2                - Originating machine: veeam.university.veeam.local                - Service machine: veeam.university.veeam.local                - Not exposed                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}                - Attributes:  Auto_Release DifferentialNumber of shadow copies listed: 1

Здесь мы видим, что успешно создался снапшот со своим Shadow copy ID, и для удобства ему сразу присвоили алиас VSS_SHADOW_1. Этими данными вполне можно оперировать, если возникает такое желание. Однако не будем уходить в сторону и попробуем прочитать содержимое этого снимка. Для чего подмонтируем его в качестве диска.

DISKSHADOW> expose {a1eef71e-247e-4580-99bc-ee62c42221d6} Z:The shadow copy is a non-persistent shadow copy. Only persistent shadow copies can be exposed.

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

DISKSHADOW> delete shadows all # или только нужный IDDeleting shadow copy {a1eef71e-247e-4580-99bc-ee62c42221d6} on volume \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ from provider {b5946137-7b9f-4925-af80-51abd60b20d5} [Attributes: 0x00420000]...Number of shadow copies deleted: 1

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

DISKSHADOW> add volume C:DISKSHADOW> set context persistent # вот этот моментDISKSHADOW> createAlias VSS_SHADOW_1 for shadow ID {346d896b-8722-4c01-bf01-0f38b9abe20a} set as environment variable.Alias VSS_SHADOW_SET for shadow set ID {785983be-e09d-4d2a-b8b7-a4f722899896} set as environment variable.Querying all shadow copies with the shadow copy set ID {785983be-e09d-4d2a-b8b7-a4f722899896}        * Shadow copy ID = {346d896b-8722-4c01-bf01-0f38b9abe20a}               %VSS_SHADOW_1%                - Shadow copy set: {785983be-e09d-4d2a-b8b7-a4f722899896}       %VSS_SHADOW_SET%                - Original count of shadow copies = 1                - Original volume name: \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ [C:\]                - Creation time: 17.05.2021 19:38:45                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3                - Originating machine: veeam.university.veeam.local                - Service machine: veeam.university.veeam.local                - Not exposed                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}                - Attributes:  No_Auto_Release Persistent DifferentialNumber of shadow copies listed: 1

Как мы видим: Attributes: No_Auto_Release Persistent Differential. Поэтому если теперь вы сделаете expose, то снапшот примаунтится как полноценный диск, по которому можно перемещаться и копировать с него файлы. Диск, само собой, виртуальный и состоит из блоков оригинального диска, плюс блоки изменившихся данных, читая которые, мы можем видеть состояние оригинального диска на момент снапшота. Всё просто.

Только учтите, пожалуйста, такой момент, если вдруг решите, что нашли святой грааль: в таком режиме нельзя занимать данными больше 50% места на диске. Один блок свыше - и всё, диск переполнился.

Что тут хочется ещё сказать, а вернее, спросить: если всё так просто, то почему же я говорю, что всё так сложно? Проблема в том, что, отдавая на боевом сервере команду vssadmin create shadow, мы, конечно, создаём какой-то снимок, но как себя будут чувствовать приложения после отката на этот снимок, мы предсказать не можем. Это не шутка: команда create признаёт наличие ошибок при выполнении как вариант нормы. Райтер не вернул вовремя Ок от приложения? Да кому это надо, го делать снапшот, я создал.

Поэтому когда за дело берётся настоящее бекапное приложение вроде Veeam Backup & Replication, то речь идёт не об одной команде, а о целой россыпи предварительных запросов, в результате которых формируется огромнейшая команда (это не метафора для красного словца, а реальность), в которой учитываются состояния райтеров и приложений на целевой системе, с жестким требованием соответствия всех статусов необходимым. Словом, количество мест, где что-то может пойти не так, вырастает на порядок. Ведь нам главное - не снапшот создать, закрыв глаза на сопутствующие потери, а гарантировать консистентность данных внутри него.

Как лечить VSS

Сразу, не отходя от кассы, открою вам тайну самого лучшего метода лечения большинства проблем с VSS - перезагрузка. Понимаю, что это кощунство и кошмар наяву для всех свидетелей аптайма, но суровая правда жизни такова, то можно сколь угодно долго биться с пациентом, чтобы потом всё починилось само от перезагрузки. Да, именно так. Это тот случай, когда само сломалось и само починилось.

Другая проблема - это железо. Помните про временные рамки для райтеров? Про десять секунд на снапшот? Для многих это ограничение становится проблемой из-за того, что СХД физически не успевает сделать требуемые действия за отведённое время. Как это лечится? А вот никак. Или покупаем более мощное железо, или ищем пути снижения нагрузки, чтобы операция была проведена за выделенный промежуток времени.

Если посмотрите одно из самых популярных KB1680: VSS Timeout when backing up Exchange VM, то легко обнаружите, что первые три шага для решения всех проблем с VSS - сделайте снапшот вручную и посмотрите чтобы это заняло менее 20 секунд, перезагрузитесь и попробуйте снизить нагрузку. Вот так и живём, да.

И что же делать, если VSS падает, в ивентах ничего нет, а понять, что происходит надо? Тут я могу порекомендовать три хороших статьи:

• КВ от Veeam, посвящённое анализу поведения VSS с помощью diskshadow.

• Другое KB от Veeam, посвящённое сбору информации с помощью vsstrace из Windows SDK. Но скажу сразу, это уже не для слабых духом.

• И видео от моего коллеги, где он наглядно показывает, как работать с информацией из первых двух пунктов =) Рассказывает он действительно хорошо, но с непривычки голова у вас от объёма информации заболит, это я вам обещаю.

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

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

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

Так что да, эта статья скорее для тех, кто начинает - о том, как может быть на самом деле (нежели для прошедших горнило замены картриджей и теперь пугающих этим молодёжь).

Что за человек такой - инженер Technical Customer Support в Veeam Software?

В идеальном мире это тот самый универсальный человек, требования к которому сформулированы сухим кадровическим текстом в описании вакансии. И швец, и жнец, и на дуде игрец. Вот только есть одна небольшая проблема его не существует. Так что если вы не знали, то держите первое открытие за сегодняшний день: вакансии, как правило, пишутся под идеального кандидата в вакууме, которого никто никогда не видел. А если даже такой вдруг покажется на горизонте, то его с руками оторвут. Отсюда вывод: если вы не подходите под все пункты в описании вакансии, это нормально, и можно смело откликаться. Если только пропущенные пункты не помечены как критически важные. Тут уж действительно мимо.

Но вернёмся к нашему инженеру техподдержки в Veeam. И да, это наш блог, так что простите, но пишем мы про то как всё устроенно именно у нас, а не у соседей. Так вот, все его навыки можно объединить в три группы: это технические скилы, знание языка и умение общаться с клиентами. Сразу возникает вопрос: а что важнее? Можно же взять сисадмина и научить его разговорному английскому. Или выпускника филфака за недельку натаскать по книжкам а-ля VMware for Dummies. А самого последнего грубияна - отправить на курсы придворного этикета, где его научат родину любить и вилкой с ножом пользоваться, и с людьми вежливо общаться. Но вас тут ждёт большое разочарование: мы в Veeam ищем комбинацию всех трёх навыков в одном человеке. Любой и каждый желающий вступить в наши стройные ряды обязательно проходит все три этапа отбора. К нам трудно попасть, легко потерять и . ну вы и сами знаете.

На практике этапы отбора могут идти вразнобой, но давайте представим, что первым будет техническое собеседование. И как вы думаете, что же можно спросить у кандидата, если твои продукты - это корпоративный софт, и вероятность того, что кандидат их хотя бы видел, крайне мала? Про то, что он их использовал хотя бы в рамках домашней лаборатории, даже фантазировать не будем. Правильно, спросить можно всё что угодно, только не про сам софт. Поэтому техническое собеседование -- это разговор про IT-кругозор кандидата и имеющиеся у него навыки. Вся наша работа строится вокруг множества технологий. Среди них гипервизоры VMware и Hyper-V, Nutanix AHV, Azure, AWS, Oracle, SAP HANA и так далее. Но мы не ожидаем, что кандидаты знают их так же, как и мы. Нет, но если они могут хоть как-то поддержать разговор про виртуальные машины, то им сразу плюсик в карму, тут без сомнений. И мы не ожидаем, что они могут хотя бы час заливаться соловьём, сравнивая особенности работы корпоративных СХД. Или что готовы без запинки объяснить разницу между Ms SQL, MySQL, Oracle и Redis. Нет, ничего такого знать совершенно не требуется. Всему, что надо будет, проще потом научить, но вот базу кандидаты знать обязаны.

Что такое реестр в винде, зачем нужны виртуальные машины, почему домены водятся в лесу, как пинг связан с эхо, а шутка про udp может и вообще не дойти. Если хоть что-то из предыдущего предложения вызывает у кандидата затруднения, то у него нет этой самой базы. Если человек хотя бы улыбнулся в процессе чтения этих вопросов, то, похоже, в этой голове что-то есть. Ведь учиться читать, не зная букваря, сами понимаете, затея гиблая. Поэтому ещё раз: каких-то супер-узких знаний мы от кандидатов не ждём (но если они есть, мы будем только рады), но уверенные знания уровня молодого сисадмина быть должны строго обязательно.

Далее следует проверка уровня владения иностранным языком. Возьмём для примера английский, как самый популярный. (Хотя у нас бывают вакансии и для знающих французский, немецкий и вообще примерно любой, отличный от русского. Но не суть.) Суть в том, что самый частый вопрос в нашу сторону, само собой, про необходимый уровень языкового навыка. И самое типичное уточнение от кандидатов: Ну я документацию нормально читаю. В принципе. А пару раз даже писал в зарубежный саппорт письма. Ну что же, ты большой молодец. Спору нет. Однако есть проблема: этого объективно мало. Наш инженер должен уметь разговаривать с клиентами ртом.

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

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

Из всего вышесказанного вывод язык надо знать на разговорном уровне. Пусть и не идеально грамматически, пусть без RP-прононса, но наш инженер должен смело говорить Welcome, понимать, что ему говорят, и не запинаясь говорить в ответ. Это называется поддерживать диалог. По нашим наблюдениям, такие знания начинаются на уровне intermediate и есть практически у всех, кого стандартные языковые тесты оценивают как upper-intermediate. Но не переживайте, мы не доверяем оценку навыков бездушным тестам. Ведь основная задача любого теста - это проверить способность человека проходить этот тест, а не выявить его реальный уровень знаний. Поэтому основное заключение здесь дают наши внутренние преподаватели английского, проводящие интервью. И, надо признать, на этом этапе проваливается довольно много кандидатов. Но давайте будем честными сами с собой: без английского в наше увлекательное время в IT-индустрии приходится довольно туго.

И завершающим этапом служит так называемый customer care. Вещь пока малоизвестная по стране в целом, но очень важная для всех, кто работает с западными рынками. Заключается она не только в умении быть вежливым и красиво выходить из любой ситуации, но и в том, чтобы любить человека как класс. Чтобы даже самый лютый негативщик сиял от радости после общения с нашим специалистом. Тут ведь штука какая: к нам крайне редко звонят, чтобы просто сказать спасибо за наш супер-крутой софт и отличный сервис. Обычно на звонок людей побуждает наличие какой-то проблемы, которую надо решить здесь и сейчас. То есть звонящий априори раздражён, ему плохо, и он совершенно не против на ком-то сорваться. Возможно, даже поорать. И вот тут ваши навыки общения, умение оставаться вежливым и искреннее желание помочь человеку с его бедой выходят на первый план. И вы не поверите, но мы и этому всему научим, а на входном тестировании кандидатов интервьюируют люди, профессионально занимающиеся проблемами customer care. (Да, бывают и такие.)

Теперь соберём всё вместе. Идеальный (но несуществующий) кандидат - это сисадмин, развивший свои навыки дальше замены картриджей и переустановки винды. Он устал от типовых проблем у типовых юзеров и хочет расти как технический специалист. Поэтому он неплохо владеет английским на достаточном для поддержания осмысленной беседы уровне. А также способен проявлять чудеса выдержки при общении и неизменно вежлив.

А теперь зайдем с другой стороны

Чего ради такому замечательному специалисту идти работать к нам в техподдержку? Пусть даже в гордом звании инженера.

Ответ в самой сути работы. Вот, например, получил товарищ свой первый опыт в техподдержке провайдера. Чем он там занимался на первой линии? Сидел целый день с телефоном в обнимку, просил перезагрузить роутер по питанию и проверял достаточность денег на счету. Возможно, он даже перешёл с первой линии на вторую, и ему доверили десять простых команд на аксесных свичах. А по праздникам разрешили прописывать MAC-и и vLAN-ны.

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

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

А вот наши инженеры с пользователями (в обывательской трактовке термина пользователь) не работают. Совсем и никогда. Наши клиенты - это такие же сисадмины, как и они сами. Они не просят починить принтер, переключить монитор в соседнюю розетку и поменять обои - они содержат инфраструктуры, зачастую огромные и напичканные топовым железом, куда простых смертных на пушечный выстрел не подпускают. И наши инженеры техподдержки - не простые смертные. Они - профессионалы, в которых уверены мы сами и которым доверяют другие инженеры со всего света.

И вот вам первое же отличие: они и не сидят на телефоне целый день. Они набирают из очереди кейсов, отключаются от звонков и занимаются их решением. Потому что на первой же линии мы решаем до 80% обращений. А это, напомню, не истории про зависший роутер, а серьёзные инфраструктурные задачи такого уровня, который львиная доля его бывших коллег может себе только нафантазировать. И то, если наберётся достаточной смелости.

Почему мы так безапелляционно утверждаем, что инфраструктуры сложные, а задачи интересные? Здесь можно просто посмотреть на список наших клиентов и представить, что звонить будут инфраструктурщики крупнейших банков, гигантских международных корпораций и прочих компаний, про которые знает буквально каждый. А ведь мы им не корпоративы с бегом в мешках устраиваем, а решаем проблемы с инфраструктурой, в которой могут быть сотни, а то и тысячи элементов.

Youre in the army now

Ладно, предположим, что кандидат прошёл через горнило отбора, и мы все рады приветствовать нового члена нашей команды. Теперь уже коллеге выдали стол, стул, компьютер, чашку и прочие ништяки новичка, но что будет дальше?

А дальше его ждут три месяца интенсивного обучения. Причём с умным видом дремать на лекциях не получится можно считать, что это обучение без отрыва от производства, с учебными KPI. Где-то с середины программы постепенно начинается работа с кейсами. Поэтому к концу испытательного срока от новобранца ожидается где-то 30-40 закрытых кейсов и уже какие-то свидетельства того, что инженер может применить полученные знания на практике.

Само собой, первым делом ему выделят ментора и начнут подтягивать уровень технических знаний по всем необходимым нам областям. Это гипервизоры, сети, различные операционки, СУБД, СХД, облака и многое другое. Даже если он решит уволиться спустя эти три месяца, с таким набором знаний его с руками отрывают в любую купи-продай контору на должность старшего сисадмина. Но так скоропостижно увольняются только уверенно придерживающиеся методологии Сам Себе Злобный Буратино. Настоящий инженер уже почувствовал, что в IT-мире бывают интересные и нетривиальные задачи, за решение которых платят приятную зарплату, поэтому зачем опять идти торговать помидорами?

Ладно, вернёмся к обучению. Пока новичок будет старательно впитывать базовые инфраструктурные вещи, мы начнём учить его работе с нашими продуктами. Это отдельный пласт знаний, который, кстати говоря, весьма неплохо ценится на рынке труда даже сам по себе. И как только новичок научился ориентироваться в этом море информации, случится страшное он получает первый настоящий кейс. Вернее, он берёт его сам. Скорее всего, этот кейс будет предельно простенький, а за действиями нового инженера будет тщательно следить ментор, но всё будет хорошо. Следом будут простые звонки клиентам, когда надо что-то уточнить в их запросе, но рано или поздно он примет свой первый настоящий звонок, и уже никто не будет знать, с чем к нему обратятся на том конце провода. Возможно, просто уточнят что-то по настройкам, а возможно, там упал прод и надо срочно всё поднимать. Но бояться здесь нечего, так как всю дорогу на протяжении этих месяцев ментор будет наблюдать, подсказывать и при малейшем намеке на непонимание советовать, как лучше поступить. Ведь если у нас есть тренировочные кейсы, то тренировочных клиентов у нас нет. Они все настоящие, и права на ошибку мы не имеем.

Кстати, про тренировки. Как любому спортсмену нужен удобный зал с хорошими тренажёрами, нашим инженерам нужна хорошая лаборатория для работы. Ведь нельзя научиться работать с топовыми технологиями, не имея к ним доступа. Поэтому наша лаборатория (или лабораторный стенд, если угодно) - это нежно любимое, постоянно обновляемое и оберегаемое детище, которое, вполне вероятно, мощнее всего, что ты видел до этого. И у каждого инженера там есть свой кусочек счастья с доступом до всех железок и высокотехнологических игрушек.

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

А если захочется расти не только в ширину, но и в высоту, то и здесь есть все шансы. В сплочённые ряды нашего сапорта ещё не взяли ни одного тимлида или руководителя со стороны. Все работающие у нас тимлиды и директора выросли из рядовых инженеров. Поэтому с тебя - хорошая работа, с нас - возможности реализации твоих хотелок.

Итого

Инженер техподдержки, как видите, это не низшее звено в цепи эволюции IT специалиста, а серьёзная работа. Ведь в первую очередь он всё-таки инженер. А как и в любой инженерной специальности, тут всё зависит исключительно от человека. Захочет станет признанным мастером своего дела и посвятит ему всю жизнь. И не важно, будет это работа у станка или со временем захочется научиться руководить другими инженерами. Хороший специалист никогда не пропадёт, а его работа должна (и будет) хорошо оплачена. А даже если со временем он решит кардинально сменить профиль деятельности, то всегда можно легко это сделать, с блеском применяя полученные ранее знания и умения.

Ну и напоследок хочется дать совет - остерегайтесь мест, где гордое звание инженера лепят на всё подряд, включая замену картриджей и прописывание вланов. Это ещё не инженеры, это на них учатся...

^{Сокращённая версия этой статьи была залита ещё и на хх.}

Как и у каждой уважающей себя техподдержки, у инженеров Veeam есть свой список самых популярных поводов позвонить им в любое время дня и ночи. Это и вечно молодое У вас неправильно работает ретенш, и никогда не стареющее У меня место на дисках кончилось, что делать?, и прорва других.

Однако среди них есть простой, казалось бы, вопрос. Он объясняется за 5 минут, но вот парадокс: его объяснение вылетает из головы в течение следующих тридцати секунд. Звучит этот чудо-вопрос примерно так: После бекапа Veeam нарисовал мне непонятный график и написал, что у меня загрузка сорса 63%, прокси 48%, сети 99%, а таргета 0! А потом ещё и обозвал этот сорс ботлнеком, а у меня там ого-го какая железяка! И что вообще означают эти проценты?

Сегодня объясню в текстовом виде, чтобы было куда возвращаться и перечитывать на досуге.

Bottleneck (бутылочное горлышко, если переводить в лоб) - самая медленная часть вашей бекапной инфраструктуры. Узкое место или слабое звено, если хотите. Тот самый нехороший человек, которого семеро ждать не должны, но получается, что ждут. Если переключиться на более технический язык, то эта та часть инфраструктуры, в которой данные в среднем проводят больше всего времени. То есть обрабатываются дольше всего. Получается, что это чистой воды вопрос производительности (перфоманса, как принято говорить). И знание ответа на этот вопрос позволит нам понять, какую часть в цепочке обработки данных надо ускорить, дабы повысить общую скорость процесса.

И тут откровение номер раз: чтобы говорить о перфомансе на серьёзных щщах, надо напрямую измерять интересующие нас метрики и проводить их аналитику. Это статистика загруженности дисков, процессоров, памяти и так далее. Словом, построить внутри одного продукта ещё один продукт, только мониторинговый. Поэтому Veeam ничего напрямую не измеряет, однако в логах можно найти шесть метрик, сделанных путём опосредованных измерений.

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

ТПоэтому давайте немного посмотрим на суть происходящих процессов. Как уже неоднократно говорилось, процесс любого бекапа связан с работой двух агентов: так называемого сорсного и таргетного. Один данные откуда-то читает и передаёт второму, который эти данные куда-то записывает.Если мы говорим про классический бэкап VMware, то сорсной агент читает блоки данных с VMFS, сжимает их при необходимости, дедуплицирует в рамках одного диска, шифрует и пуляет по сети в сторону таргетного агента.Таргетный, в свою очередь, читает данные, прилетающие по сети, сжимает или разжимает их (да, в этом мире всякое может быть), дедуплицирует ещё раз, но уже на уровне разных дисков, и записывает их на диск или шару, именуемые бэкапным репозиторием. И так до конца создания бекапа.

Специфика работы агентов сильно (очень!) различается в зависимости от типа джобы и её настроек, но в упрощённом виде каждый агент делает три последовательных операции: Чтение > Обработка > Запись. Соответственно, нас интересуют четыре метрики, которые могут сильно меняться в зависимости от настроек джобы. Они же и есть те самые ботлнеки:

• Source: время, затраченное на получение данных от хоста.

• Proxy: время, потраченное на всякие вспомогательные операции на наших прокси, т.е. на дедупликацию, шифрование, сжатие и т.д.

• Network: сколько затрачено времени на передачу данных от сорсного агента к таргетному.

• Target: как долго мы писали данные в файл бекапа.

Однако, чтобы не усложнять себе жизнь с абсолютными значениями, проще придумать неких процентных попугаев - то есть шкалу, где 0% - это практически полное отсутствие загрузки, и 99% - это когда можно шутить про шутер, превратившийся в пошаговую стратегию (то есть данный элемент загружен полностью и тормозит работу остальной системы). Поэтому откровение номер два: ботлнеки измеряются сразу на трёх уровнях: на уровне всей джобы, отдельной таски и так называемых PEX (на всякий случай, это по-английски написано пекс).

Джоба

В логах каждой уважающей себя джобы можно найти что-то вроде такого:

[08.10.2020 05:02:37] <01> Info     [JobSession] Completing session '220209b6-8b62-4b0e-b66a-0b55d7dc3c07'[08.10.2020 05:02:37] <01> Info     Load: Source 78% > Proxy 67% > Network 48% > Target 0%[08.10.2020 05:02:37] <01> Info     Primary bottleneck: Source[08.10.2020 05:02:37] <01> Info     Backuped size: 258,3 MB, total backuped size: 84,2 GB[08.10.2020 05:02:37] <01> Info     Job session '220209b6-8b62-4b0e-b66a-0b55d7dc3c07' has been completed, status: 'Success', '100 GB' of '100 GB' bytes, '1' of '1' tasks, '1' successful, '0' failed, details: '', PointId: [cac85195-54b9-49b4-a8c7-2baaa9bfd607][08.10.2020 05:02:37] <01> Info     [BackupJobPostActivity] JobSession '220209b6-8b62-4b0e-b66a-0b55d7dc3c07' PostActivity: 'AskService'

Это самая натуральная средняя температура по больнице, которая высчитывается на основе данных от всех объектов в бекапе. То есть если в рамках одной джобы вы бекапите машину с быстрого хоста и машину с медленного хоста, да ещё и на удалённой площадке, качество этих данных будет примерно никакое. По этому куску лога видно, что бекапится одна машина ('1' of '1' tasks, '1' successful, '0' failed,) и данной статистике можно верить.

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

Тут надо сделать важное отступление, которое называется Veeam Agent for %%%%. В силу особенностей своей работы агенты зачастую неспособны адекватно оценивать возникающие задержки. Так что на данные из их логов нужно смотреть с достаточной долей скепсиса. Например, загрузка прокси для агента это загрузка CPU на бэкапируемой машине. И что там будет с локальными задачами на момент запуска бэкапа тайна великая, а проценты загрузки непредсказуемы. А как мы помним, ботлнеком назначается та часть цепочки передачи данных, которая показала наибольшую задержку в процентах.

Возникает вопрос: как именно считается усреднение? Отвечаем: работает принцип наследования.

• В рамках джобы усредняется значение всех тасок внутри неё.

• В рамках каждой таски усредняются значения по всем дискам машины.

• Функции, где нет взаимодействия с машинами (File to Tape, File Copy, Backup Copy etc) считают средние значения для обрабатываемых файлов.

Task

Теперь опустимся на уровень отдельных тасок. В их логах уже появляются значения PEX

[05.10.2020 05:01:49] <06> Info     Using changed block tracking for disk '[vuesx02-ds1] vudc01/vudc01.vmdk'[05.10.2020 05:01:52] <39> Info                   [AP] (6dea) output: --asyncNtf:disk_capacity: '107374182400'[05.10.2020 05:01:54] <39> Info                   [AP] (5613) output: --size: 107374182400[05.10.2020 05:01:54] <26> Info                   [AP] (5613) output: --pex:0;1048576;0;1048576;0;32;98;0;0;0;0;0;132463369144510000[05.10.2020 05:01:57] <26> Info                   [AP] (5613) output: --asyncNtf:--fsaware_skip:45828014080:0[05.10.2020 05:01:57] <26> Info     Skipping deleted file blocks: source '5613', message '45828014080:0'[05.10.2020 05:01:57] <39> Info                   [AP] (ff74) output: --asyncNtf:--fsaware_skip:45828014080:0[05.10.2020 05:01:57] <26> Info                   [AP] (5613) output: --pex:100;107374182400;591396864;60954771456;591396864;164645529;74;64;44;98;64;0;132463369178880000[05.10.2020 05:01:59] <12> Info                   [AP] (5613) output: <VCPCommandResult result="true" exception="" />[05.10.2020 05:01:59] <07> Info                   [AP] (5613) output: <VCPCommandArgs />[05.10.2020 05:01:59] <07> Info                   [AP] (5613) output: >

Итак, у нас есть интересующая нас строчка: [05.10.2020 05:01:57] <26> Info AP output: --pex:100;107374182400;591396864;60954771456;591396864;164645529;74;64;44;98;64;0;132463369178880000

Давайте разбираться в этом заборе из цифр:

• 100 Текущий % переданных данных от объёма диска.

• 107374182400 Сколько данных было прочитано и обработано (в байтах)

• 591396864 Сколько из них оказалось полезными (не нулями). Тоже в байтах.

• 60954771456 Количество пропущенных данных (в байтах)

• 591396864 Сколько данных было реально прочитано после пропуска пустых блоков и не изменившихся в соответствии с CBT (тоже в байтах)

• 164645529 Количество переданных байт. В нормальных условиях всегда будет меньше, чем количество прочитанных, т.к. передача осуществляется после дедупликации и сжатия.

  • 74 Загрузка сорсного агента при операциях чтения (в %)

  • 64 Загрузка CPU на машине с сорсным агентом (в %) (среднее значение)

  • 44 Загрузка сорсного агента при передаче данных (в %)

  • 98 Загрузка таргетного агента при приёме данных (в %)

  • 64 Загрузка CPU на машине с таргетным агентом (в %) (Среднее значение)

  • 0 Загрузка таргетного агента при операциях записи(в %)

• 132463369178880000 Количество затраченного времени

Как мы видим, по сумме значений основным ботлнеком, кажется, получается сорсной агент. Это же будет отображено в интерфейсе.Однако пара значений 44-98 - это сеть между сорсом и таргетом. Поэтому интерпретировать ситуацию надо следующим образом: сеть между сорсом и таргетом весьма медленная относительно возможностей сорса читать, а таргета записывать. Таргет бы и рад писать больше (у него загрузка 0%), но данные не успевают приходить. Сорсной агент читает данные достаточно близко к своим возможностям (74 и 64), а вот его сеть откровенно бездельничает больше половины времени.

И надо замолвить пару слов про альтернативный формат, который был представлен в Veeam Agent for Linux 3.х. Этот формат для простоты называется pex\vpex:

• VPEX формат используется при volume-level бекапе с использованием veeamsnap модуля

• PEX формат используется при file-level бэкапах (не важно, с или без veeamsnap модуля) и при работе с BTRFS дисками.

Записи в логах выглядят примерно так:

[14.02.2019 20:39:54] <140192883136256> lpbcore| vpex: 5498732544/5498732544/0/5498732544/2893106400 / 88/47/10/90/56/9

Как мы видим, отсутствует только процент выполнения и затраченное время. В остальном всё без изменений.

Примеры

Теперь давайте рассмотрим несколько показательных вариантов ботлнеков.

• 0;12;99;99;0;1 - Сеть с обеих сторон загружена на максимум. Типичная картина при Backup Copy на удалённую площадку. Делаем канал шире или экспериментируем с WAN Accelerator.

• 0;75;98;98;0;1 - Практически то же самое, только загружен процессор у сорсного агента. Значит, можно попробовать получить прирост за счёт добавления процессорной мощности прокси, и/или выставить режим сжатия послабее. Однако со вторым вариантом есть нюанс может подскочить нагрузка на сеть, и всё станет хуже, чем было.

• 0;12;99;0;0;99 Ботлнек здесь репозиторий. Если в его качестве используется CIFS на удалённой площадке, то первое дело для исправления ситуации расположить там же таргетный прокси (т.к. при записи на сетевую шару таргетный агент запускается на прокси, а не на самом сервере).

• 75;56;78;32;16;78 На первый взгляд кажется, что здесь вся инфраструктура нагружена довольно равномерно. Однако вполне можно обнаружить, что диски могли бы работать быстрее, в то время как мы тратим мощности на какие-то сторонние операции.

• 99;12;0;0;0;1 Диски хоста явный ботлнек. Вернее, не сами диски, а скорость чтения данных. Стоит проверить, в нужном ли месте расположена ваша прокси и в каком режиме она читает данные. Но совсем откидывать версию, что диски фуфло, тоже не стоит ;)

• 0;0;0;45;90;45 Прокси на таргете утыкается в процессор. Просто добавь CPU (воды). Типичная картина для больших Full бэкапов.

• 79;22;85;17;10;95 А это типичный вид инкрементального бекапа (или реверс-инкремента, не суть) при слабом репозитории. Пока сорс активно читает данные, а сеть их активно передаёт, репозиторий не успевает их записывать.

Инструменты для тестирования инфраструктуры

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

Начнём с начала, то есть с источника данных (аkа сорса). В большинстве случаев это будет VMware или Hyper-V хост. И, само собой, для их тестирования используются разные инструменты.

Когда речь идёт про vSphere, тут лучший тестировочный инструмент это VixDiskLibSample. Это простенькая C++ программа, идущая в комплекте с VMWare VDDK, которая использует библиотеку vixDiskLib. То есть более корректные результаты, чем она, вряд ли кто покажет. Про эту тулу не так давно была целая статья, так что всем интересующимся обязательно к ознакомлению.

А когда речь заходит про Hyper-V, то тут есть целая россыпь доступных инструментов. Поскольку диски самих машин лежат на обычных виндовых дисках, достаточно будет классического DiskSpd, про использование которого у нас есть отдельная КВ статья. Правда, в ней есть одна то ли бага, то ли военная хитрость было замечено, что при записи рандомных данных она может генерить, скажем так, недостаточно рандомные данные. Поэтому в отчётах может не сильно, но подвирать.

Другая классика жанра это iostat и iometer.

• Вариантами использования второго уже весь интернет исписан, включая наш блог.

• А первый это просто утилита для мониторинга загруженности дисков, которую достаточно просто запустить.

Причём гонять тесты этими тулами можно смело и на сорсе, и на таргете. Если говорить о предпочтениях, то я бы сказал так: на виндовых машинах с помощью Diskspd хорошо тестировать NFS и SMB шары, а на линуксе есть встроенный dd, которого в большинстве случаев хватает за глаза.

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

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

На этом на сегодня всё. Следите за нагрузками и да прибудут с вами быстрые бекапы.

Япония влечет своей необыкновенной культурой, потрясающей природой и развивающимися во все стороны технологиями. И интереснее наблюдать и изучать ее изнутри, не как турист, а как житель. Я провела в Токио год, полный приключений и разнообразных открытий. Я влюбилась в эту страну, но для себя решила, что жить в ней не хотела бы. Прежде всего потому, что лицо и душа страны это её жители, а познать и подружиться с ними с нашим культурным багажом очень сложно. Раскрою вам несколько полезных вопросов, которые вас заинтересуют, если вы планируете или уже собираетесь переезжать в Японию:

Виза

Если вы уже нашли работу или учебное учреждение в Японии, работодатель / языковая школа / ВУЗ пришлёт вам DHL или другой курьерской службой доставки Certificate of Eligibility (или Сертификат, определяющий статус заявителя в Японии). Этот документ гарантирует, что работодатель / школа / ВУЗ несет за ответственность за ваше стабильное финансовое положение в Японии и будет оказывать необходимую поддержку. Вместе с этим документом и остальными (полный список здесь) вы отправляетесь в Посольство для подачи заявления на визы. (Лучше предварительно проверьте часы работы Посольства в период карантина и порядок подачи заявлений. Документы также принимают по почте, также только оригиналы). Рабочую или учебную визу выдают быстро (мне дали через 3 дня после подачи заявления), но процесс также может быть немного затянут в связи с последствиями пандемии. Если у вас пока нет приглашения от работодателя, и вы для начала хотите оглядеться, вы можете получить только туристическую визу (список документов для подачи заявления на туристическую визу). По ней вы не сможете работать и учиться, но после получения приглашения от будущего места работы или учебного заведения можно будет подать на визу соответствующего типа. Самая долгая туристическая виза действует 3 месяца, специально под нее языковые школы предлагают учебные программы. За этот срок можно более или менее понять, захотите ли вы тут учиться, жить и работать.

ID-карта ( или дзайрю:ка:до)

Это аналог паспорта, выдается тем иностранцам, кто планирует провести в Японии срок более трёх месяцев. ID необходима для оформления банковской карты, аренды жилья, оформления страховки и т.д. Получить ID можно в отделе миграционной службы, при этом за студентов документы подает учебное заведение (языковая школа, ВУЗ или другое), за сотрудников компания или сам сотрудник (в зависимости от политики работодателя).

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

Полицейские в Японии очень вежливые и дружелюбные, но вот одна моя знакомая девушка, которая оставила дома ID, была доставлена в участок и отрабатывала на общественных началах какое-то количество часов в качестве наказания за отсутствие ID. Конечно, они проверят вас по базе, но наказание всё равно пропишут, так что лучше иметь ID всегда с собой.

Прочие документы

Прописка, страховка, свидетельство о рождении ребенка оформляются в или куаякусио: (администрации) по месту проживания. Лучше всего сюда приходить с провожатым, говорящим и читающим на японском языке, т.к. обычно японцы либо не говорят по-английски, либо стесняются в этом признаться. Для получения прописки необходим договор аренды квартиры и ID. Страховка оформляется при наличии ID.

Страховка платная. Мне, как студенту университета, пришлось оплачивать страховку в администрации, в общежитии и в самом ВУЗе. Общая сумма примерно 470$. Страховка покрывает лечение и медицинские осмотры (кроме частных клиник, подробнее о медицине напишу ниже), аварийные ситуации, когда вы причинили ущерб другому человеку или чужому имуществу, и наоборот. При аварии нужно получить справку от полиции для подачи в страховую компанию.

Японский язык

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

Это удивительно, но в Японии можно прожить без знания местного языка. Конечно, если вы хотя бы на бытовом уровне можете объясниться с жителями Японии вам будет комфортнее: спросить дорогу, попросить о помощи, уточнить информацию в банке и т.д. Я знаю несколько человек, кто живет и работает в Токио больше трех лет, используя в основном английский язык для работы и общения с друзьями, и базовый японский в быту. Они работают в иностранной компании, в свободное время общаются с англоговорящими иностранцами или японцами и совсем не чувствуют необходимости учить японский язык. Названия улиц, станций и прочие информационные таблички дублируются на английском языке. Возможно, вы не заблудитесь, но, если вы не знаете языка запаситесь карманным wi-fi и внешним аккумулятором для телефона. Если всё же вы ищете школу японского языка, могу порекомендовать Yu Language Academy.

Работа

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

Сложно однозначно оценить отношение к иностранцам в японских компаниях. Где иностранных сотрудников много к ним привычны, где мало иностранцы выделяются. В японском обществе вы в любом случае будете себя чувствовать чужим, в большей или меньшей степени. Это лично мое мнение, но я чувствую, что русские скорее индивидуалисты, и каждый действует, отталкиваясь от своей морали и привычек. А японцы живут и мыслят как группа где бы они ни находились, каждый человек чувствует себя частью определенной группы. Он ничего от нее не скрывает и действует ей во благо. Кстати, японцы любят себя называть хатараки бачи (пчела-работяга), работающие на благо улья.

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

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

Деньги

Если вы устраиваетесь на работу или поступаете в учебное заведение, находясь в России, с оформлением документов вам помогут коллеги или представители школы / университета. Нас, студентов, просто брали за руки и водили по всем инстанциям, и нам даже не нужно было общаться с их сотрудниками. Также было и с банком мы пришли туда группой, по очереди подходили на оформление карт и получали их через 2-3 дня. Для оформления банковской карты нужен ID и прописка. У иностранцев могут быть ограничения по онлайн-банкингу, это уже зависит от банка.

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

Аренда жилья

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

По этой причине в съемных квартирах и комнатах ничего нельзя клеить на стены, и вообще нельзя как-либо портить их, пол или имущество за это могут потребовать компенсацию, когда вы будете съезжать. Моей знакомой пришлось заплатить $600 за небольшое количество пролитого средства для снятия лака на линолеум. Скорее всего, вы не найдёте объявления о сдаче жилья, в которых будет написано с детьми нельзя. Но в отношении домашних животных есть некоторые особенности: квартирантам с собаками легче найти варианты жилья, чем любителям кошек. Возможно потому, что кошки точат когти об мебель. Возможно потому, что многие японцы заводят себе именно миниатюрных собачек и просто более лояльно относятся к собакам. В Токио нет системы центрального отопления, поэтому обогреваются зимой квартиры обогревателями. Я знаю японцев, которые экономят на электричестве зимой и просто не снимают верхнюю одежду дома. Мы часто проводили время в библиотеке. Японские дома довольно холодные и по нашим меркам хлипкие. Как объясняют сами жители островов, дома строят с учётом того, чтобы в случае землетрясения или сильного цунами их не восстанавливать, а стоить новые.

Средние расходы на коммунальные услуги в месяц составляют примерно $180. Из них на электричество приходится $100, на воду $40 и на газ $40. Японцы могут вызвать полицию, если у вас в квартире будет шумно или даже просто людно. При этом если вы объясните полицейским, что вы не шумите, или они сами это поймут, вас просто предупредят. Если же вы действительно шумите полицейские составят рапорт и направят его потом на ваше место работы. Выселять же из квартиры вас будут только за что-то серьёзное, для этого нужно постараться.

Связь

Еще несколько лет назад процедура приобретения сим-карты для иностранца была очень сложной ее можно было купить только вместе с телефоном, заполнив кучу документов. Сейчас всё намного проще, для покупки сим-карты и телефона нужен ID и банковская карта. Среди тарифных планов нет безлимитных. Если вы не планируете надолго оставаться в Японии лучше купите карманный wi-fi роутер (пример на Amazon). Портативный роутер позволяет организовать доступ к интернету с нескольких устройств сразу, независимо от того, какой тариф какого оператора на них используется. Все устройства, подключенные к такому роутеру, пользуются интернетом в рамках установленного на нём тарифного пакета. То есть если на роутере оплачен безлимитный пакет, он будет безлимитным для всех устройств, подключенных к нему. К портативному роутеру можно подключить не только смартфон или планшет, но и любое устройство, оснащённое wi-fi модулем.

Но если вам очень важна высокая скорость интернета, то можно подключить домашний интернет (стоимость очень разнится, от $50 до $100). Найти и выбрать провайдера будет не сложно как только вы поселитесь в квартиру, ваш почтовый ящик будет забит рекламными листовками. У вас будет время спокойно просмотреть их и сравнить. Здесь вы можете прочитать про мобильную связь и ознакомиться с предложениями разных провайдеров. При оформлении сим-карты заключается договор на обслуживание, который обязательно нужно расторгнуть перед отъездом из Японии. Меня очень впечатлили истории о студентах, которые уехали домой с открытым договором и получали через некоторое время внушительные счета за связь.

Общественный транспорт

В Японии очень удобная система общественного транспорта. Расскажу на примере Токио: прежде всего нужно приобрести карту Suika, можно сразу в аэропорту или на любой станции метро. Стоимость карт варьируется от $10 до $100, при этом $5 от стоимости карты не могут быть использованы для оплаты проезда (они составляют залоговую стоимость и могут быть вам возвращены, если вы сдадите карту по окончании периода пребывания в Японии). Остаток является депозитом для оплаты проездов, баланс карты можно пополнить в терминалах на станциях метро. Удобство Suika еще и в том, что ею можно расплачиваться в некоторых магазинах (7-Eleven, Wallmart, etc.), кафе и столовых. Здесь более детальная информация про Suika, в том числе видеоинструкция покупки и использования: https://www.jreast.co.jp/e/pass/suica.html.
Этой картой можно пользоваться и в других регионах, помимо Токио:

Транспорт в Японии двигается в безупречном соответствии с расписанием, из-за этого кажется, например, что автобусы передвигаются чересчур вальяжно. Лучше заранее планировать свой маршрут, я использовала Google maps и выбирала кратчайший и простейший путь, внося станцию отправления и прибытия в поиск.

В автобусах оплата на выходе водителю (которые выглядят вышедшими из сказки, в красивой синей форме и белых перчатках), картой Suika или наличными. Наличные опускаются в автомат, который сдачи не выдает, поэтому если картой вы не обзавелись разменяйте монетки. Стоимость проезда на автобусе зависит от расстояния и района города, например, в центре города $1.99 (городской автобус), $2.08 (частный). Есть автобусы по $0.95 (на окраине города).

Система железных дорог в Токио сведет вас с ума в первого взгляда, но если её не бояться и регулярно пользоваться поездами, разберетесь очень скоро. В Токио есть Tokyo Metro и Toei Subways, у них разные пути, которые очень удобно комбинировать.

Кстати, закладывайте в расчеты время на ориентирование на местности. Однажды я заблудилась в городе-станции Токио, у которой есть несколько выходов на разных этажах, целые улочки с рынками, магазинами и ресторанчиками. Я спрашивала дорогу у прохожих и у сотрудников станции, но никто не смог помочь мне сориентироваться (хотя вопросы были сформулированы на японском). Тут пошла в ход стратегическая хитрость я обозначила для себя ориентир, и всегда приходила к нему как к стартовой точке, от которой можно легко найти нужное направление: Gin-no-Suzu Square (Silver Bell Square или Площадь Серебряного Колокола).

На станциях ориентироваться легко везде есть указатели, но здесь будьте внимательны, т.к. встречаются очень похожие названия линий и станций. Можно также спросить сотрудников станции, они говорят на ломаном английском и языке жестов. Стоимость билетов Tokyo Metro и Toei Subway не зависит от категории поезда есть Regular train и Rapid Train, вам просто нужно выбрать тот, который быстрее доедет до нужной вам станции,и не пропустить её ).

Возможно, вы об этом знаете, но на всякий случай напомню: в Японии нельзя разговаривать в общественном транспорте по телефону и слушать громкую музыку в наушниках. И вообще всячески шуметь. Также не принято уступать место напоказ пожилым людям и беременным женщинам. До того, как я это поняла, я немного испугала одну японку. Она села на моё место, но чувствовала себя некомфортно.

Личный транспорт

Аренда квартиры с парковочным местом стоит дорого, поэтому в основном местные жители и экспаты используют общественный транспорт или велосипед. Мы с одногруппниками сразу купили себе велосипеды. Стоимость велосипеда зависит в первую очередь от модели. Очень распространены велосипеды типа мамачаиро (mother and child) простые взрослики с корзинкой на руле и багажником, к которому можно докупить безопасное детское кресло. Они стоят ориентировочно $100. Дороги в Токио очень комфортные, нет резких подъемов или разбитого асфальта, поэтому передвижение на велосипеде это не только польза для здоровья, но и большое удовольствие. При приобретении велосипеда он регистрируется в магазине на ваше имя, и если вашим транспортом воспользуется кто-либо другой, он может быть задержан полицией для выяснения обстоятельств.

Правила дорожного движения в Японии отдают приоритет пешеходу и велосипедисту перед машиной, поэтому вы всегда будете правы в случае любых недоразумений на дороге. Мне знаком случай, когда велосипедист врезался в стоящую на парковке машину, заработав лишь пару синяков, а владелец готов был оплатить ему лечение в частной клинике только чтобы велосипедист не начинал с ним судиться. Если вы всё же рассматриваете вариант покупки машины, стоит учесть, что аренда квартиры с парковочным местом стоит на порядок дороже. Да и в целом в Токио очень проблемно найти свободную парковку, а пробки не дадут свободно передвигаться по городу. Здесь вас спасет car sharing, он очень распространен в Токио. Японцы, у которых нет своего автомобиля, берут его в аренду для путешествий на один-два дня (ориентировочно $70 в день).

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

Покупки

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

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

Приведу примеры стоимости некоторых продуктов:

• Молоко 1 литр (3,5%) $2.40 Выбирайте молоко из Хоккайдо на упаковке вы увидите надпись или силуэт острова. Кстати, будьте готовы к тому, что жирность и сам вкус молочных продуктов будет другой будто немного разбавленный.

• Яйца (10 шт) $2.40

• Хлеб $1.20-$2.40 Сложно найти не сладкий хлеб, но вам этот квест может понравиться. Ищите пекарни по манящему запаху, в магазинах обычно продается хлеб для сэндвичей и булочки.

• Сыр 126 гр. в пластиках, 7 шт. $1,70. Первое время после прибытия в Токио я готовила еду сама, но очень скоро заметила, что питаться в кафе или покупать готовую еду дешевле. Кстати, многие супермаркеты делают большие скидки на готовую продукцию в последний час работы.

Медицина

В Японии есть государственные клиники и частные клиники. В государственной клинике вы можете пройти обследование или лечение по страховке, в частной только за деньги.Отдельно остановлюсь на стоматологических услугах: лучше не лечите зубы в Японии! При потрясающе развитых технологиях средний уровень стоматологических услуг ниже, чем в России. Это подтверждают и наши стоматологи, которые лечат приезжих японцев. В Японии распространено использование металлических вкладок и накладок в стоматологии. Я встречала многих студентов, у которых были такие даже на передних зубах. Это считается даже модным, но с точки зрения современной стоматологии использование металла не является передовым методом.

Будьте готовы к тому, что в аптеках drug stores, которые встречаются довольно часто в магазинах с бытовой химией и косметикой вам не продадут лекарства без рецепта и не дадут совета при выборе медикаментов. В аптеках работают продавцы, а не фармацевты, и они либо продадут вам тот товар, который вы назовете, либо попросят рецепт врача.

Подработка или арубайто ( )

Этот пункт, возможно, будет интересен студентам языковых школ и университетов. Разрешение на работу можно получить, если ваша виза и срок обучения длится более полугода. У меня была стипендия, и я могла бы получить разрешение только при отказе от неё. Для подработки вам нужно уметь говорить на уровне повседневного общения, читать и немного писать по-японски. Если вы не уверены в своих знаниях можно найти подработку среди русскоязычных пользователей фейсбука в группах типа Помогаем нашим. Там также публикуются вакансии для специалистов со знанием японского и другая интересная информация, так что присоединиться к сообществу будет полезно. Кроме фейсбука существует множество сайтов для поиска работы, на них отдельно останавливаться не буду.

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

Дети

Ребенок, родившийся на территории Японии, получается Свидетельство о рождении, которое выдается на основании proof of birth ( сюссёсиомейсё) своеобразной справки из больницы. При этом ребенок считается гражданином того же государства, что и родители. Во время регистрации ребенка в администрации родители получают медицинскую книжку на ребенка, в которой будет вся информация о приемах врача во время беременности, пройденные учебные классы для беременных, протекании родов, состоянии здоровья матери и ребенка, и многое другое.

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

Стереотипы

Да, японцы находятся на работе допоздна, и вы зачастую можете увидеть человека в костюме спящим на ступеньках перед входом в станцию. Но не все японцы при этом трудоголики. Просто принято уходить с работы после того, как уйдет домой руководитель. Ты можешь при этом заниматься чем угодно, придавая своему лицу серьезный и деловой вид главное уйти позже, показав этим, насколько для тебя работа важнее личной жизни.Да, они не против выпить. Но многие японцы пьянеют от одного стакана пива и становятся похожими на глупо хихикающих детей. Очень мило, но не очень весело.Кстати, в Японии курят в барах и ресторанах. Есть также заведения, которые запрещают курение в помещении. В общественных местах есть специально отведенные зоны, вне которых курить нельзя, но курить просто на улице не возбраняется.Возможно, извращенцев много. Об этом предупреждают все: если в час-пик в вагоне метро ты чувствуешь, что кто-то начинает к тебе непотребно прикасаться или фотографировать твои ноги и т.д. нужно указать этого человека и громко сказать хэнтай или чикан (извращенец), и люди сами вытолкают его из вагона и сдадут служащему станции. Я ни разу не встречала подозрительных типов, но очень часто слышала предостережения и это уже заставляет задуматься. Кстати, некоторые поезда начинаются с розовых вагонов, куда нельзя входить мужчинам они точно безопасны.

Да, японцев можно назвать стеснительными. Это связано по большей части с культурными особенностями нельзя быть индивидуалистом, нельзя блистать своими знаниями и талантами, нельзя говорить, что тебе что-то удаётся. И в случае с английским языком японец может сказать, что он на нём говорит очень плохо, даже если находится на уровне Advanced.

Да, японцы крайне пунктуальны (по большей части, но могут быть исключения). Их время распланировано на недели вперёд, у них есть четкий график для каждого мероприятия. Поэтому на спонтанный поход в кофейню не все согласятся.

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

Этот пункт возвращает меня к предисловию статьи почему я не хотела бы жить в Японии. В этих глубинах культуры и объемности смыслов очень часто чувствуешь одиночество. Иностранец не является частью контекста Японии. Кроме того, Япония это страна для интровертов, и большую часть японцев можно назвать интровертами. Они держатся на дистанции, и границы её настолько холодны и непонятны, что и ты сам постепенно возводишь вокруг себя защитную стену. Вам поможет любимое дело (а в Японии только ленивый не найдёт себя) и другие иностранцы, с ними вы будете чувствовать себя на одной стороне.

Пока я писала этот текст, я очень старалась избегать категоричных суждений. Их очень легко выносить, но также легко можно и ошибиться. Возможно, вам японский менталитет будет близок, и вы очень комфортно будете себя ощущать в Японии. Это настолько тонко, что можно почувствовать только самостоятельно. Не бойтесь, но будьте готовы!

Автор: Наталья Героева (Veeam), Project Manager.