Что с reg.ru
Сайт reg.ru недоступен в поддержку не написать, мой сайт zvonili.fun из-за этого как и многое другие не работает...
Что с reg.ru?
Кто знает и когда решится проблема хз куда писать...
Сайт reg.ru недоступен в поддержку не написать, мой сайт zvonili.fun из-за этого как и многое другие не работает...
Что с reg.ru?
Кто знает и когда решится проблема хз куда писать...
Evolution Hosting предоставляет пожизненно бесплатно VPS-хостинг, чтобы получить бесплатный пакет, они требуют, чтобы вы разместили баннер их сайта на главной странице своего сайта » в зависимости от качества вашего веб-сайта, они предоставляют вам любой пакет из своих тарифных планов, также они не принимают заявки на веб-сайты порнографического характера - подходят только качественные сайты.
Бесплатный пакет VPS Hosting предоставляют навсегда. Мой один хороший знакомый получил пакет стоимостью 80€, таким образом если у вас качественный сайт, вы можете допрыгнуть и до тарифа стоимостью в 100€.
ЧТО НУЖНО ДЕЛАТЬ:
1. Заполняем форму на сайте.
2. Ожидаем ответа от компании.
└ Отвечают около 7 дней
3. Размещаем баннер на сайте.
4. Получаем KVM VPS Hosting.
В новом выпуске подкаста «Релиз в пятницу» Миша Шпаков, Кира Айрапетова, Олег Филимошин обсудили грейды: когда, кому, зачем они нужны и как эффективно их использовать.
Если коротко, вот что я выделила для себя:
- Грейд — структура, позволяющая привязать зарплаты в компании к навыкам и задачам сотрудников.
- Грейды нужны не всем компаниям.
- Грейды не только про hard-skills.
- Грейды обоюдно удобны, если позволяют тем, кто больше вкладывает в развитие компании, получать больше.
- Грейды могут быть вертикальные и горизонтальные.
Круто, когда человека сам решает, куда он хочет развиваться, и компания идет ему навстречу.
Под катом подробнее — текстом для тех, кому удобнее почитать, и ссылочка на видео для тех, кто предпочитает слушать.
Миша Шпаков — dev тимлид VDS.
Кира Айрапетова — руководитель HR в Timeweb.
Олег Филимошин — архитектор Timeweb Cloud.
Миша Шпаков (МШ): Всем привет, это подкаст «Релиз в пятницу» от компании Timeweb. Сегодня мы поговорим о грейдах в IT и не в IT-компаниях. Нужны ли они? Что это такое? И как с этим жить? Меня зовут Миша Шпаков, сегодня мне помогут Олег и Кира. Представьтесь, пожалуйста, и расскажите о себе.
Олег Филимошин (ОФ): Меня зовут Олег Филимошин, я работаю архитектором облака в Timeweb. Я застал много всяких вариаций того, как оценивать скилы разработчика, сам принимал участие в составлении программ и проектировании процесса оценки специалистов, поэтому я постараюсь чем-то поделиться.
Кира Айрапетова (КА): Меня зовут Кира Айрапетова, я работаю руководителем HR-отдела компании Timeweb. Я занималась в течение своей карьеры и доработкой грейдов, и разработкой грейдов, поэтому тоже хотела бы поделиться мыслями на этот счет.
МШ: Класс! А вообще, какое-то непонятное слово «грейд», что это такое?
КА: По сути, это структура для оценки снизу доверху. Началось это где-то в конце ХХ века, когда люди, которые управляли компаниями, поняли, что выдавать зарплаты из воздуха — это не очень удобно. Поэтому они придумали систему грейдирования. И мы все, особенно в IT, на ней едем по сей день.
МШ: Слушай, а вот джуниор, мидл, синьор — это оттуда?
КА: Да, но я думаю, что мы еще обсудим этот вопрос. Это тоже грейдирование, но не всегда оно правильное и не всегда хорошо используется.
МШ: Слушай, а вот ты начала говорить, что это используется для мотивации — только для мотивации или есть еще какие-то причины внедрения грейдов?
КА: Для введения грейдов существует несколько причин. Грейды полезны как бизнесу, так и разработчикам или другим сотрудникам, но мы IT-компания, так что будем говорить о разработке и о разработчиках.
Грейды нужны в компании, чтобы растить своих сотрудников в соответствии с потребностями бизнеса.
У нас есть грейд, скажем тот самый, не очень удачный «джуниор / мидл / синьор».
Чтобы в одной компании быть джуном, тебе достаточно знать язык «X» и набор технологий «Y» на каком-то, определенным компанией, уровне. Чтобы быть мидлом, тебе нужно знать всё это уровень выше, плюс уметь делать это самостоятельно. Чтобы быть синьором, знать технологии еще на уровень выше, и уметь обучать джуниоров, к примеру.
Какое-то общее понимание, что такое «джуниор / мидл / синьор», может быть похожим от места к месту.
Если мы говорим про конкретные грейды при оценке, то еще должны оцениваться конкретные скилы, знание технологий и так далее. «Джуниор/мидл /синьор», то нас в компании должны знать PHP, JS на одном уровне, а если человек приходит из другой компании или идет в другую компанию, там будут абсолютно другие требования.
Тот, кто в одном месте синьор, в другом может быть джуном, и наоборот. Бывают люди, которые говорят: «Я джун, я вообще ничего не знаю, меня не повышали 20 тысяч лет, я, наверное, совсем дурак» А потом он приходит и пилит архитектуру. Такое тоже бывает.
Грейды полезны для бизнеса, компания помогает человеку расти так, как полезно для компании. Человек должен оценивать себя здраво и должен понимать, что все компании работают по-разному. У человека должно быть объективное адекватное восприятие своих навыков и понимание того, где он эти навыки применит.
Еще существует бюрократическая история — карта компетенций, карта развития сотрудника. Это хорошо, но сложно. У разработчиков все немного проще: есть, допустим три грейда — что ты должен сделать, чтобы подняться на следующий, есть perfomance review, ты должен его пройти.
Конечно, я сейчас, все максимально упрощаю, так делать не очень правильно. Но если мы объясняем «на пальцах», это достаточно понятная схема развития для сотрудника. Компания показывает своему сотруднику, чего он должен добиться, чтобы поднять зарплату, скиллы и так далее.
Поэтому я за грейды, но за грейды, сделанные правильно. Очень часто компании совершают ошибки в их внедрении, потому что они не понимают, какую цель они преследуют. Более того, они даже не понимают, как это делать.
В итоге, отвечая на твой вопрос, да, это полезно, и бизнесу и сотрудникам, и грейды используют не только для мотивации.
ОФ: Я тоже хотел добавить. На самом деле, хорошо, если эти грейды прописаны.
А то приходишь в компанию, а там все на каком-то «подсознательном уровне» чувствуют, кто они есть и куда им двигаться. Потом осознанные люди начинают задавать вопрос «А куда я развиваюсь?» и всё рассыпается. Так что очень хотелось бы, чтобы грейды были прописаны. Хотя бы в Confluence.
КА: Мне кажется, документация нужна всегда и везде, хотя бы в минимальном количестве.
МШ: Олег, у тебя богатый опыт. Ты работал на разных позициях во многих компаниях. Можешь рассказать, что ты думаешь в целом о грейдах и о них, как о системе мотиваций?
ОФ: Сам по себе, в отрыве от других процессов, грейд — это не система мотиваций. Я хотел вкинуть мысль, которую нам следует обсудить — а только ли хард скиллы входят в грейды?
ИП: Нет. Я уже говорила, что джуна, мидла и синьора друг от друга отличает инициативность и самостоятельность. Это как раз про социальные навыки. Они везде почти одинаковые, но их тоже надо прописывать.
ОФ: Очень хорошо, если эйчар знает и умеет это использовать.
Раньше никто ничего не прописывал. В должностной инструкции написано что-то. Разработчики приходили, посидели, поработали как-то, деньги получили. Зарплата и «квалификация» пересматривались, когда разработчик приходил с офером из другой компании, и сообщал о том, что уходит. Если он был ценным сотрудником — руководство его тормозило, давало чуть больше денег, чем предложили в другом месте, и разработчик оставался.
Позже IT-отрасль в России стала развиваться и появлялись осознанность и осмысленность. Появились процессы по пересмотру уровня и зарплаты. Часто шел запрос на повышение уровня и з/п от разработчиков, так как они не развивались. Люди хотели не просто денег, но еще и расти в своей специальности.
В последнее время стали появляться компании, где все прописано. Часто в таких компаниях сильная команда HR-ов. Тебя знакомят с процессами, как только приходишь в компанию. В таких компаниях любой новичок знает, что через полгода будет ревью, он к нему готовится и прекрасно знает, что ему требуется сделать, чтобы повысить свою зарплату или квалификацию в рамках компании.
Мне доводилось участвовать и организовывать процесс работы с техническими специалистами, в него входила возможность оценить человека на входе в компанию по грейдам. И есть замечание, что очень плохо оценивать разработчиков тремя конечными грейдами.
Допустим, человек не развивался, был синьором, рынок поменялся. Новые сеньоры, приходящие в компанию, могут быть сильнее его по навыкам, иметь бОльшую з/п, и у человека возникнут вопросы к руководству.
Еще круто, когда компания может оценить кандидата на должность и дать ему обратную связь, если человек не подходит для компании, ему подскажут, что нужно подтянуть, чтобы ему были рады в этой компании.
КА: Да, есть люди, которые после нормально фидбэка возвращаются на собеседование, подтянув свои навыки.
ОФ: По той же системе можно оценить работника в период испытательного срока. Ожидания компании изложены письменно, можно пальцем аргументированно показать, что стоит подтянуть, а с чем человек круто справился.
Грейды — это инструмент, который не всегда подходит в контексте. Бывает контекст, когда у тебя кросс-функциональная команда, здесь неплохо подходит механизм с ролями.
Есть роль, у роли есть критерии и ты их можешь совмещать. Как дерево развития навыков в компьютерных играх. Это открывает глаза людям, что они могут не только в своей линейке раскачиваться. К примеру, прописав роли, компания может повысить количество фулстеков, если ей это выгодно. Или склонять больше людей в менеджерство.
Не все сеньоры могут менторить. Люди могут не уметь, не хотеть или не знать, что так можно. Поэтому мы ввели роль ментора. Это было формализовано, ты мог найти карточку сотрудника-ментора и узнать, с развитием каких компетенций он может помочь. У нас появилась внутренняя платформа для обучения (менторства). И появилась она благодаря тому, что мы это прописали, проговорили и рассказали остальным.
МШ: Вы назвали много плюсов, но у меня грейд ассоциируется с аутсорс-компаниями. Многие мои друзья работают в таких компаниях. Они рассказывают, что это очень стрессовая история, когда ты знаешь, что раз в полгода у тебя проверка, и ты боишься провалиться. А так как разработчики — часто интроверты, для них это нервирующая процедура, которая снижает продуктивность.
КА: Я думаю то, о чем говорят твои друзья — особенность их компаний. В крупных компаниях такие процессы действительно приносят стресс в жизнь, потому что требования не гибкие, они не про людей, а только для регламента. А то, что делается для регламента — всегда плохо.
Я за то, чтобы грейды были гибкие, многоуровневые, для сотрудников. И говорю о тех грейдах, которые работают в обе стороны. Иногда грейды вводятся, чтобы элементарно давать своим сотрудникам причину для НЕповышения зарплаты. Так бывает. Скорее всего, с этим связан негатив твоих знакомых.
Я за то, чтобы если сотрудник развивается, растет и тащит компанию вперед, то он получал больше. В идеале, грейды должны быть про это.
ОФ: У меня есть еще одна теория, почему для аутсорсеров грейды могут быть стрессом. При таких процессах, оценка тебя как сотрудника, происходит раз в полгода, а в остальное время ты не знаешь, что о тебе скажут.
КА: И более того, если мы говорим про грейды в крупных аутсорс- компаниях, оценка производится по хард скиллам. По каким-нибудь выполненным задачам из таск-трекера.
Ни твоя инициативность, ни твой бизнес-ориентированный подход, ни твое желание обучать джунов не влияют на это. Могут даже забыть посмотреть, что последний проект ты делал на PHP, который для этого ты и выучил, а до этого не знал. Это полная шиза, так использовать грейды.
Грейды — отличный инструмент, если его применять правильно. Если вводит грейды, которыми ты собираешься кошмарить людей, то получишь отток сотрудников. Грейды — это мотиватор, помощь компании и очень удобный инструмент оценки, чтобы двигать человека дальше, что выгодно обеим сторонам.
Я HR, не разработчик. Я могу оценить разработчика по софт-скилам, а что мне дальше делать с этой оценкой без грейдов — непонятно. Когда разработчики оценили хадр-скилы кандидата, я, зная должность, на которую мы ищем человека, могу понять, потянет он работать в проекте наравне со всеми, или это джун, которого стоит посадить писать запросы для базы данных, и пусть растет и проявляет инициативу.
ОФ: Также можно сравнить несколько кандидатов.
ОФ: Кто придумывает грейд в компании?
КА: В компании, если мы говорим о разработчиках, это должна быть смежная работа архитекторов, эйчаров и людей, которые оценивают и принимают решение, тимлидов, к примеру.
И грейды должны периодически пересматриваться, так как рынок очень подвижный. Следовать грейдам, которые написаны 2 года назад бесполезно. Это закладывают при разработке грейдов.
МШ: Давайте попробуем разобраться. У нас есть общепринятая практика на рынке. Есть три уровня специализации и кажется это очень мало.
КА: Что такое джун/мидл/синьор. Это три позиции, которые человек будто бы должен в своей жизни занимать. Есть еще тимлид. Хорошо, 4.
ОФ: Это странно, словно обязательно ты должен в тимлида вырастать.
КА: Ну да, будто менеджерская — это обязательно. На самом деле, нет. Если ты не хочешь заниматься менеджерством, это тоже допустимо. Джун/мидл/синьор — очень узко профилированная оценка, она не дает широты понимания всех навыков сотрудника.
Когда ты фулстачишь, выполняешь какие-то продуктовые задачи или частично проджект, тестируешь свой код, становится совсем непонятно. Ты джун чего? Или мидл чего? Будто бы ты делаешь все, но при этом непонятно, на каком уровне.
В идеале грейды должны быть многоуровневые, должны быть грейды в глубину и в ширину.
Допустим, сотрудник знает PHP на 10/10, JS на 5/10, еще знает базы данных, может работать с продуктами. Для грейда конечная цель — не только развитие, но и зарплата. Она должна складываться не только из того, что ты сеньор на PHP, но и из других навыков. Так, по моему мнению, должны выглядеть хорошие грейды.
Опять же, это система, к которой нужно прийти, она сложная, не все ее могут себе позволить, не у всех даже есть в этом потребность.
В рамках компании из 7 человек, какое-то интуитивное разделение джун-мидл-сеньор может быть нормально. Но не всегда понятно, что с ними и с компанией будет потом.
ОФ: Бывают еще очень редкие вещи, в которые никто не верит. Когда оценивается вся команда, команда полностью отвечает за свой результат и их зарплата зависит от их результата. Тогда грейды пропадают, они не нужны. Постарались хорошо — получите деньги, плохо — разберитесь внутри, в чем было дело.
КА: Это вопрос очень высокой самоответственности.
ОФ: И вопрос масштабирования. Для компании в 400-500 человек, это звучит почти нереально.
МШ: Как компании понять, что она готова к внедрению грейдов? Как это определить?
ОФ: Первое — у компании нет грейдов (смеется).
КА: Есть какие-то маркеры.
Стоит подумать о внедрении грейдов, когда начинается неразбериха в найме, неразбериха в мотивации сотрудников, когда не совсем понятно, что делать с зарплатами, потому что рынок не стабильный. Грейды — это в любом случае какая-то стабильность.
Когда эти маркеры начинают проявляться, стоит задуматься над введением структуры. Грейд — это структура. Структура нужна не всегда и не везде, я люблю творческих хаос, он классный, особенно если мы говорим про какой-то продуктовый подход. Но структура местами делает хорошие вещи гораздо лучше. Когда ты понимаешь, что у тебя происходит что-то непонятное, пора ввести структуру.
ОФ: Про маркеры. Самый важный маркет — когда приходят люди и говорят «Я не знаю, куда развиваться, я увольняюсь». Если все хорошо и все понимают, куда развиваться, и в бизнесе все хорошо — потребности в грейдах не возникает. Тогда нет проблем, пусть работает само.
МШ: Вы проговорили социальные навыки, роли, конкретные обязанности. Куда мне как специалисту расти, если я уже условно «сеньор», например?
КА: Можно в менеджеры. Это максимально про социальные навыки. Если ты хочешь управлять людьми, ты можешь — тогда ты это делаешь.
Если нет, то ничего нет плохого в том, чтобы развиваться как специалист. Хороший специалист, синьор, может отвечать только за техническую сторону разработки. Не за то, чтобы команда была мотивирована, а именно за то, как будет развиваться стек. То есть может расти и дальше в глубину. Технологии развиваются. Если ты синьор, и хочешь дальше оставаться синьором, ты все равно будешь расти за этими технологиями.
МШ: Но если я сеньор, то предполагается, что я уже на максимальном уровне и зарплаты и какого-то развития своей компании.
КА: Есть дополнительная мотивация, индексация за стаж, какие-то бонусы за участие и принесение пользы бизнесу. Есть способы мотивации сотрудников, которые не растут в менеджмент.
ОФ: Все зависит от компании. Если в твоей компании специалист видит, что у разработчиков зарплата n-я, а у всего менеджмента nx2, то разработчик рано или поздно догадается, куда идти.
Если в компании зарплаты уравнены, как на западе, где зарплата менеджмента ниже, чем у крутого специалиста, то сама компания тебя подталкивает развиваться больше в техническую сторону.
МШ: А как правильно показывать, какой у тебя грейд, надо ли делать его открытым? Чтобы я знал, допустим, что у Васи такой-то грейд, такой-то уровень и такая-то зарплата или это должно быть закрыто?
КА: К открытому грейду еще нужно прийти. Открытые зарплаты могут себе позволить не все компании в силу разных причин, это не только финансовый вопрос.
ОФ: Но все же это основная причина. Рынок труда сейчас — это биржа. Разработчики одного и того же уровня с разницей в 2-3 месяца взятые на работу, к сожалению, получат, скорее всего, разные зарплаты.
КА: Вопрос открытости — вопрос частный. От бизнеса к бизнесу. Кого-то это привлечет, а кого-то оттолкнет.
ОФ: Тут есть проблема. Разработчик может прийти за повышением зарплаты, так как у «соседа» другая зарплата. Он задается вопросом «чем я хуже?». Зарплата используется как инструмент оценки.
Но не всегда это оценка, часто бывает, что зарплата того или иногда специалиста сложилась из нужд. К примеру, у соседа х2, т.к. у него ипотека и трое детей, сейчас он просто не сможет нормально жить на меньшее. Но когда об этом узнает специалист со схожими обязанностями, у него будет ощущение, что его обделили, и меньше ценят. Это сложный вопрос.
МШ: Как правильно проводить скоринг специалиста?
ОФ: Я не уверен, что есть такое понятие «как правильно». Нельзя ответить, как правильно. Бывает как лучше, исходя из конкретных задач.
МШ: Допустим, мы в Timeweb вводим сетку грейдов, чтоб оценить своих сотрудников. Что я как тимлид должен сделать?
КА: Сначала эта сетка прописывается в зависимости от требований бизнеса, то есть надо понимать, что нужно бизнесу в данный момент. Ты оцениваешь, насколько твои сотрудники способны согласно грейдам эти задачи выполнять. Дальше можно сотрудников корректировать. Если ты понимаешь, что сотрудник хороший, слегка не дотянул, его можно обучить, его можно мотивировать. Но это в идеале, если компания не очень большая.
ОФ: Возможно Миша спрашивает про то, как этот процесс непосредственно организовать?
МШ: В том числе. На самом деле, есть несколько вопросов. Давай с этого начнем.
ОФ: Как минимум это психологически интересный момент. Человек сам себя может оценить по этой же системе. И можно потом свести с оценкой, проводимой компанией. Таким образом, человек может узнать, насколько адекватно он себя оценивает.
МШ: А если мы говорим об инструментах для оценки? Допустим, мы провели опрос 360. Это все равно нацелено на субъективную оценку тимлида, одного человека, который принимает решение. Или нет?
ОФ: А это как вы сделаете. Чаще всего собираются рабочие группы. Из кого их собирать, тоже от вас зависит. Либо это люди из твоей компетенции, либо это разносторонние люди, либо это представители бизнеса.
КА: Это люди принимающие решение, но у них должны быть компетенции на принятие этого решения.
ОФ: Хочу добавить, что обычно это стоит очень дорого. Раз в полгода какие-то ключевые лица от работы отстраняются, они занимаются ревью около месяца, в зависимости от размера компании. В итоге из полугода, человека занимается основными рабочими задачами только 4-5 месяцев. Это приводит к тому, что в какой-то момент начинают оценивать раз в год, качество ревью падает. Нужно искать баланс и выбирать такой процесс, чтобы это не затягивать, не превращать в дорогое бесполезное удовольствие.
МШ: Есть ли еще что-то помимо грейдов, что позволяет правильно работать с сотрудниками и мотивировать их?
ОФ: Лучший способ — это хорошая развитая обратная связь в команде.
Не нужно ждать, когда к тебе придет эйчар, скинет заранее подготовленную форму, и потребует заполнить. Эйчар может быть не в курсе, что вы друг с другом не работаете, хотя сидите рядом и кушать вместе ходите.
Так что, если у вас хорошо развита обратная связь, то скорее всего, как только встречается какая-то проблема в команде, сотруднику дадут обратную связь, он тут же продолжит развиваться дальше. Этот цикл петли обратной связи грейды обязывают проводить хотя бы раз в полгода. Если это развивать как часть культуры, то даже грейды не понадобятся.
КА: Это действительно вопрос хорошей коммуникации между руководителем и командой.
ОФ: Это вектор, куда стоит двигаться. Грейды — это способ прийти к нормальному фидбэку через формальный процесс.
МШ: Как часто надо устраивать performance review?
КА: Раз в полгода — это оптимальный промежуток времени, потому что дорого, во-первых, а во-вторых, полгода — это достаточный срок для человека, чтобы он помимо задач, которых обычно в работе много, мог как-то прокачаться.
Ты же не только на рабочих задачах развиваешься, ты что-то извне потребляешь. На это нужно время, нужно время, чтобы освоить, применить в работе.
ОФ: А еще раз в полгода, потому что в отпуска люди уходят, сезонность подбирается. Не обязательно развитие — это про какие-то хард-скилы, может нужно прочитать книгу, а может повысить уровень английского, чтобы техническую литературу свободно читать. Это нельзя сделать за месяц или за пару дней. Скорее всего это займет много времени.
Но, например, когда мы формировали процесс, мы заложили возможность досрочного пересмотра. Если человеку поставили большую цель и он справился за 2 месяца, то ему не нужно ждать еще 4 месяца.
МШ: Я для себя узнал очень много сегодня и очень интересно было с вами пообщаться.
В итоге, что грейд — это очень крутая штука, если использовать правильно. Они нужны не всем компаниям, компания сама должна понять что ей нужно — грейды или что-то другое.
Грейд строится не только на технических навыках, а также на массу навыков, также хорошо, когда они включают в себя какие-то роли и задачи.
Круто, когда человек сам говорит, куда он хочет развиваться и компания идет ему навстречу. Спасибо за разговор, было интересно в этом разобраться.
В Индонезии хостинг подбираю местный. Какие-то жуткие цифры в охулиардах. Зато IT-везде такое типовое и ламповое.
Как там визой то платить.
Приплыли. Пойдем искать другого хостера. Или Заполнить своими данными? Как там у них с законами Х.З. Скажут Иноагент-Террорист :)))
по поводу сгоревших серверов, тут я узнал что сгорели 25 европейских официальных серверов Rust, ну ладно это меня не сильно расстроило, на официалках особо не играю читаков слишком много, но дальше я увидел видео что там же находились русские фришардные сервера Lineage 2, и вот тут то я порадовался маленько, ибо нафиг нужны эти фришки, думаю любители фришек меня камнями закидают, ну и ладно, а я злобно похихикаю в сторонке. https://youtu.be/b0-6yWALzRA
10 марта в 02:42 по московскому времени облачным провайдером OVH было опубликовано оповещение о деградации сервиса в дата-центре SBG1 в Страсбурге, которое позже было дополнено информацией о пожаре в здании SBG2:
"В настоящее время в нашем центре обработки данных в Страсбурге произошел серьезный инцидент, связанный с пожаром в здании SBG2. Пожарные немедленно прибыли на место происшествия, но не смогли справиться с возгоранием в SBG2. Все здание было изолировано, что влияет на все наши услуги на SBG1, SBG2, SBG3 и SBG4. Если ваш сервис хостится в Страсбурге, мы рекомендуем активировать План аварийного восстановления. Все наши бригады полностью мобилизованы вместе с пожарными. Мы будем держать вас в курсе по мере поступления дополнительной информации."
SBG2 является частью кампуса SBG, состоящего из 4 ЦОД. В SBG2 предоставлялись услуги аренды выделенных серверов (dedicated) и облачные сервисы. И если облачным сервисам OVH должен был обеспечивать резервное копированием своими силами, то для арендаторов выделенных серверов эта ситуация в отсутствии резервных копий может быть фатальной.
Тем временем real-time мониторинг доступности выделенных серверов в SBG2 рапортует о полной доступности всего оборудования в ЦОД. Вероятно, сервера мониторинга располагались в том же дата-центре.
Среди облачных провайдеров, не входящих в "большую тройку" (AWS, Azure и Google Cloud), OVH является одним из наиболее популярных. Большинство из 27 дата-центров OVH расположены в Европе. Последняя крупная авария у OVH также произошла в кампусе SBG в 2017 году. В результате отключения электроэнергии весь кампус SBG был отключен. Сорок минут спустя другой кампус RBX (Рубе, Франция) потерял связь из-за несвязанной ошибки программного обеспечения в сетевом оборудовании.
Сочувствуем всем проектам, у кого сервера находились в данном дата-центре, а остальным напоминаем про давно известный чек-лист:
Храните бекапы в (сберегательных кассах) отдельных дата-центрах;
Периодически проверяйте работоспособность своих бекапов;
Имейте наготове план аварийного восстановления доступности сервиса.
UPD: В 9:20 по московскому времени пожар закончился. Судя по сообщениям Octave Klaba (основателя и владельца OVH) в Twitter, в связи с близким расположением зданий дата-центров SBG1, SBG3 и SBG4 к сгоревшему SBG2, пожарным пришлось их "охлаждать", в связи с чем в настоящий момент отсутствует доступ в эти здания и работа данных ЦОД сегодня восстановлена быть не может.
Источник: https://habr.com/ru/news/t/546264/
Может быть интересно тем, кто хочет попасть в ИТ.
Обычно нужна многомесячная подготовка, но если у вас лоб крепок, стену можно попробовать пробить.
2013 год, прошел собеседование в техническую поддержку хостинга и меня взяли на стажировку.
Я был слаб, требовалась компетенция linux, а я знал всего 5-6 команд и как выглядит консоль.
Взяли меня тогда за горящие глаза, видимо.
Мне дали стол, стул, компьютер и задание - настроить Лампу - linux, apache, mysql, php и запустить на всем этом простой сайт.
Но сделать все - на VPS, удаленном компьютере без интерфейса, только командная строка.
И все.
Я сел и понял, что я вообще ничего не понимаю, не запомнил даже названия программ. У меня не было ни одной идеи, как это все установить.
Ледяной ужас окатил с ног до головы.
Я впервые узнал про nginx, apache и php, о базе данных mysql слышал, linux в консоле видел несколько раз. CMS - это какой-то телефон?
Можно было признаться, что ничего не знаю, попросить помощи - но я жутко испугался, что меня выгонят сразу. Решил рискнуть.
Google, как установить LAMP, куча статей и гайдов. Все на английском, на русском очень и очень мало. Я не знаю языка, гугл транслейт, корявищий перевод.
Простыни конфигураций и тонны абсолютно новой информации.
Стресса я хапнул на 2 месяца вперед.
Я пил только кофе, ничего не ел, чтобы не упустить драгоценные минуты, которых может не хватить для сдачи задания.
Это был первый опыт стажировки и жестких сроков в моей жизни на работе. ТОгда я еще не знал, что вся серьезность - напускная =)
Команды, которые я запускал выдавали все новые и новые ошибки, им не было конца, я тонул без единой контрольной точки. Не работал ни один из сервисов.
До конца первого дня остается 2 часа и первый прорыв - nginx отвечает. Мой сайт сказал hello world. Да сука, сюда следующие сервисы!
Я хотел успеть все установить, чтобы потратить второй день на отладку, но навел такого бардака в системе, что решил все удалить и начать заново.
Конец первого дня - чистая машина, я все удалил. Но я могу.
Вечер с гуглом подготовки, бессонная ночь, стресс зашкаливает.
Второй день.
До 12 я успел развернуть apache, php, nginx.
Все, сайт можно сдавать на html, но подождите, осталась БД и установка wordpress - популярной CMS.
БД никак не поддавалась, для работы с ней требовалась минимальная компетенция, а не набор команд.
Экстренное гугление, ура есть инфа на русском, базовые навыки за 2 часа.
Ошибка, ошибка, ошибка …. запустилось. Твою мать, наконец то.
Установка CMS, без ошибок.
Запуск - ну да, конечно, вместо сайта меня встречает страничка hello world. Хаос с конфигами, паника, настройка, заработало.
Сдаю.
“Все ок, но не установлен SSL сертификат”
Это было задание на звездочку, но я этого не знал.
Погружение в мир сертификатов, выпуск free, привязка, готово.
Завис mysql, попытки привести его в чувство успехом не увенчались.
Я решил ребутнуть машину, чтобы запустить все сервисы заново.
Ребут - ушел за кофе, вернулся - VPS не отвечает.
ЧЕГО БЛЯТЬ
Доступ пропал, его нет. После перезагрузки машина не вышла в онлайн, а т.к. она удаленная все - я не могу показать конечную работу. Это провал!
Была общая проблема на хосте VPS серверов, я не виноват, но перезапуск был ошибкой.
Руководитель поржал и сказал - так делать нельзя.
В этот же момент он сказал, что я прошел.
Как сейчас помню - я переспросил, а что? Прошел? (Я же не знаю ничего, какое прошел!!)
Он - да, завтра заступаешь в 5/2 и оформляемся.
Эйфория по пути домой, за 2 дня я смог настроить сервер, 95% информации о котором слышал впервые.
Конечно, я не получил компетенции, использовал копипасты команд и не мог точно сказать, как он работает.
Но я его настроил.
Хостинг хорошо прокачал меня в администрировании linux, там же ступил на путь менеджмента, но это уже совсем другая история.
Но google ваш друг, он вытащит вас из любой жопы.
Для всех поклонников футбола Hisense подготовил крутой конкурс в соцсетях. Попытайте удачу, чтобы получить классный мерч и технику от глобального партнера чемпионата.
А если не любите полагаться на случай и сразу отправляетесь за техникой Hisense, не прячьте далеко чек. Загрузите на сайт и получите подписку на Wink на 3 месяца в подарок.
Реклама ООО «Горенье БТ», ИНН: 7704722037
Доброго времени суток, пикабушники!
DISCLAIMER
-----
Сразу хочу предупредить, материал будет подаваться для людей, которые далеки от темы, и слова "хостинг", "VDS", "SSL", "TLD" - не более, чем страшный набор букв. Соответственно, допущения и неточности присутствуют. Поэтому, если ты, мой дорогой читатель, имеешь о них четкое представление - смело листай дальше, полезную информацию здесь ты вряд ли почерпнешь.
Осторожно, много букв.
-----
Мы живем в очень интересное время постоянной глобализации и цифровизации жизни. Форумы, визитки, интернет-магазины, развлекательные и познавательные интернет-ресурсы... что-то вышло из моды, что-то модно, а что-то вечно. К последнему пункту, увы, относится нежелание некоторых людей (довольно больших, надо сказать) пользоваться лишний раз гуглом.
Некоторое время назад я работал в технической поддержке (далее - ТП) одного достаточно известного хостинг-провайдера, назовем его, к примеру, Суперхост, дабы не раскрывать лишнюю информацию (все совпадения случайны).В начале своего пути , я практически каждую рабочую смену я не переставал удивляться самым наивным вопросам, ответы на которые можно было бы получить, набрав в поисковике прямой вопрос за гораздо меньшее время, чем при звонке на линию технической поддержки.
Поэтому, ради эксперимента, в первом тематическом посте, мне захотелось рассказать, что же такое хостинг, каков он бывает, и почему для сайта-визитки не стоит брать выделенный сервер.
Итак, Вы решили заняться бизнесом, заявить о своем искусстве, просто создать сайт, just4fun.
Стоит задать себе несколько вопросов:
1. Готовы ли Вы поддерживать его работоспособность, регулярно актуализировать контент и, собственно, "внутренности" сайта?
2. Вам нужен относительно простой, но красивый сайт, похожий на 90% других в сети или нечто масштабное?
3. Готовы ли Вы тратить значительное количество средств на сайт?
И вот, Вы ответили на эти вопросы и решили-таки создать свой сайт.
Хотя, возможно, стоит еще подумать
Домен
Доменное имя - фактически, лицо Вашего будущего сайта. Тот адрес, что будет вводить и/или видеть пользователь в адресной строке браузера.
Для примера, домен Пикабу:
К этому вопросу стоит отнестись достаточно серьезно, т.к. приобретение нового домена будет стоить приличных средств, вернуть деньги после его регистрации невозможно, да и перенос сайта - дело, временами, трудозатратное и неблагодарное.
Я настоятельно рекомендую использовать доменное имя в .RU, .SU, .РФ зонах, если это Ваш первый опыт, т.к. процедура их регистрации подчинена законодательству РФ. А вот .COM домены, мало того, что зачастую стоят дороже, требуют еще и дополнительную услугу whois protect, без которой все Ваши указанные при регистрации контактные данные будут светиться на весь интернет на радость спамерам и другим нехорошим людям. Домены в наших, родных зонах имеют включенный whois protect по умолчанию. Да и возможность выбора имени в разы больше.
Также, перед регистрацией рекомендую уточнить на сайте регистратора наличие бесплатного DNS-редактора (о DNS расскажу в другом посте, если будет интересно)
P.S. Кстати, в некоторых случаях Вы можете не регистрировать сразу личный домен - многие хостинг-компании предоставляют т.н. технический домен. Он не особо красив, и также могут возникнуть проблемы с переносом сайта в дальнейшем, однако на первое время сойдет.
Хостинг
До этого момента в посте были красивые цветочки, а вот теперь настало время страдать с ягодками.
Что же такое хостинг?
Условно говоря - это удаленный компьютер (сервер) в различных представлениях и настроенный необходимым образом. Соответственно, хостинг-компания предоставляет Вам определенную часть своих ресурсов согласно выбранного тарифа (оперативная память, место на жестком диске, сеть, и.т.д.) и доступы к нему.
Какие бывают виды?
Тысячи их. На самом деле, все не так сложно. Основные виды можно пересчитать по пальцам одной руки:
1. Конструктор - самый простой и достаточно дешевый вид, практически не требующий знания языков программирования (а иногда - вообще не требующий). В последнее время гиганты этого сектора довели свои конструкторы до серьезных высот, и многие сайты бывает практически невозможно отличить от собранных вручную.
Однако, за все нужно платить. В данном случае - уникальностью. Подавляющее большинство безумно похоже друг на друга из-за ограниченного набора шаблонов, доступных ресурсов, и - да, здесь это минус - зачастую отсутствия возможности правки кода. Также, исходный код таких проектов зачастую закрыт, поэтому если Вам вдруг разонравятся услуги компании - перенести свое творение будет, как минимум, очень и очень сложно.
Из наиболее известных компаний - Tilda, Wix, прости господи uCoz.
Рекомендован: для сайтов-визиток, небольших магазинов, легких блогов.
2. Виртуальный хостинг - он же shared hosting, он же "почему мой сайт не работает уже сутки" - еще один распространенный вид хостинга. Значительно сложнее в управлении, чем конструктор, но все еще не требует обязательных навыков администрирования и программирования. Зачастую дороже, чем конструктор, но все еще можно арендовать по приемлемой цене. Поддерживает CMS и много других полезных вещей, при помощи которых сайт можно собрать относительно быстро и безболезненно. В руках профессионала можно придать сайту достаточно дорогой вид, но мы же с вами тут не профессионалы, верно?
Из минусов - все-таки бывает требователен к определенным навыкам. Если в конструкторе все давно сделано за вас, достаточно только тыкнуть нужные кнопочки, то для того, чтобы придать сайту вменяемый вид здесь - придется изрядно постараться. Также, в силу внутренней специфики shared-хостинга, сайт может периодически "падать" по независящим от Вас или хостера причинам, т.е. "плохие соседи по серверу". Если вдруг по сайту такого "соседа" проводят ковровую бомбардировку злоумышленники, то велика вероятность, что Ваш сайт также перестанет быть доступным. Из своего опыта могу сказать, что случается такое чаще, чем хотелось бы. Кроме того, сайт будет требовать регулярного надзора и обязательного обновления компонентов (если Вы, конечно, не хотите в один прекрасный день обнаружить вместо контента латексные изделия или рекламу запрещенных веществ). Менее серьезный на этом этапе минус - ограниченность в правах пользователя и доступном программном обеспечении (ПО). Это уже больше в сторону серьезного разработчика, нас это не особо касается.
Если Вы все же решили попробовать себя на этом нелегком пути и не ищете простых решений в виде конструкторов - это будет оптимальный вариант. Однако, запаситесь терпением, тематическими статьями и другом-сисадмином. Крайне желательно перед заказом понять, что такое CMS, как пользоваться WordPress или Joomla.
Услуги виртуального хостинга предлагают все известные мне хостинг-провайдеры, так что здесь выбор за Вами. Обратите внимание, что некоторые хостеры предлагают бесплатный тестовый тариф на 7-14 дней. Рекомендую воспользоваться, чтобы оценить свои силы.
Рекомендован: магазинам с не очень большим обхватом, начинающим веб-разработчикам, любым другим сайтам с относительно высокой активностью (~3-5 тыс. посетителей в сутки).
3. VDS - или, иначе VPS - Virtual Dedicated Server - виртуальный выделенный сервер. С этого момента все становится серьезно. Это НЕ выбор новичка.
Из плюсов - сложно говорить о плюсах и не скатываться в техническую часть. Грубо говоря - такой же компьютер, как стоит у Вас дома, только чуть менее мощный и виртуальный. Если кто-то работал с VirtualBox - в принципе, суть похожа. Полный доступ без ограничений в правах, ПО можно ставить любое не запрещенное. Пока Вы действуете в рамках закона и платите - Вы здесь царь и бог. На работоспособность сайта, в отличие от предыдущего варианта, влияет извне только работоспособность самого сервера и непосредственно Ваши злопыхатели.
Минусы - относительно дорогой и очень... нет, очень требователен к навыкам. Не имея хотя бы минимального представления об устройстве Linux-based систем, вы сделаете ровно ничего. Да, знатоки могут поспорить - но есть же визуальная панель ISPManager. Да, есть. Только её возможности также ограничены, полностью знакомства с консолью избежать не получится. Да и стоит лицензия не особо дешево. Также, зачастую более уязвим к различным атакам, чем shared-hosting из-за отсутствия распределения нагрузки и "белого" IP-адреса. От атак "изнутри" тоже никто не застрахован. Очень легко бывает удалить один-единственный "лишний" файл и самостоятельно положить все свои ресурсы. Да, такое тоже бывает.
В силу такой своей специфичности, советую обзавестись постоянным системным администратором, который будет держать на плаву и сайт, и саму VDS.
Если Вы не уверены, что Вам больше подходит - VDS или shared - выбирайте второй. На VDS всегда успеете переехать.
Рекомендован: высоконагруженным проектам (известные в широких кругах компании, интернет-магазины), системные администраторы, продвинутые разработчики.
4. Dedicated server - титан в своей отрасли. Круче только Эверест своя собственная стойка в ДЦ. Не вижу смысла отдельно его рассматривать, т.к. особенности те же, что и у VDS (только теперь Вы имеете еще и доступ к "железу". Дорого, богато, но нужно далеко не всем.
Как мы видим, решения есть под все необходимые нужды. Какие-то подойдут для самых новичков, какие-то - только профессионалам (и это мы не рассматривали многочисленные веб-студии, предоставляющие услуги "под ключ"). Однако, если Вы все же нацелены на создание сайта на отдельном хостинге - подумайте, что именно Вы ожидаете, рассмотрите различные варианты, и только потом принимайте решение.
Если кому-либо будет интересно продолжение - я с удовольствием составлю следующую часть на необходимую тему. тем более, что информации еще очень и очень много.
Успехов Вам!