Но всегда качества руководителя для успеха важнее чем качества IT-шника
И тут мы приходим к чему-то вроде «незаменимых нет»? Как раз такой подход и «губит» многих руководителей, которые относятся к разработчикам подобным образом
Отличное замечание. Тут стоит задуматься о взаимоотношениях в команде. Хороший руководитель должен быть готов воспринимать критику, а разработчик — уметь донести свою точку зрения. Очень часто все упирается в выдуманную иерархию вместо аргументов и открытого обсуждения проблем.
Это точно, но с другой стороны можно что-то более существенное сделать, если привлечь к работе дизайнера / проектировщика и часть задач по тестированию делегировать. Вопрос именно в эффективности
Кстати, в комментариях можно было бы обсудить предложения для следующих постов – какие туториалы могли бы быть интересны применительно к теме IaaS, например.
Дмитрий, никакого надувательства тут нет.
Как и указал ниже Nuur изменился параметр производительность.
Это связано с тем, что в Москве площадка построена исключительно на высокопроизводительном оборудовании. В отличии от площадки в СПБ в Москве есть только высокопроизводительный пул.
Когда Вы изменили параметр «Центр обработки данный» на Москву, конфигуратор переставил значение параметра «Производительность оборудования» на единственно возможное для Москвы значение «Высокая». При изменении параметра «Центр обработки данный» обратно на СПБ значение параметра «Производительность оборудования» на Базовая не изменилось, т.к. в СПБ доступны оба пула. В данный момент конфигуратор не видит разницы между тем, что значение параметра «Производительность оборудования» было изменено автоматически из-за смены локации или Вы его изменили самостоятельно.
Возможно это недоработка в юзабилити конфигуратора, но уж никак не «надувательство».
Но вам, большое спасибо за feedback. Мы обязательно рассмотрим этот момент и при необходимости и технической возможности внесем изменения в конфигуратор.
Хотя, справедливости ради нужно отметить, что такое поведение конфигуратора ни у кого прежде не вызывало затруднений, по крайней мере нам об этот не сообщали. Так что еще раз спасибо за инфу.
+ все-таки довольно сложно «не обратить на это внимание», т.к. кнопка заказа находится под итоговой ценой выделенной крупным шрифтом.
Иван,
1) Предлагаем Вам провести тестирование с использованием нашей инфраструктуры. Ресурсы мы естественно предоставим бесплатно.
Если вам это интересно — напишите, пожалуйста, в личных сообщениях на хабре или нам на support@1cloud.ru, или в сообщения нашей страницы в Vk https://vk.com/1cloud, конфигурацию, на которой вы бы хотели провести тест. Так же можете просто зарегистрироваться в нашем сервисе и заказать нужную конфигурацию (напишите обращение в службу поддержки там же и сошлитесь на данную статью — мы выдадим тестовый период).
2) «При этом некоторые провайдеры (например, DO) лукавят. Они дают возможность увеличивать размер виртуалки, но уменьшить её размер невозможно. Если вам больше не нужна большая виртуалка, вы должны создать новую маленькую и перенести данные на неё. Действительная возможность изменять размер виртуальных машин в обе стороны есть только у AWS, Azure и Jelastic. Если у вас она тоже есть, поправьте меня, пожалуйста.»
С радостью Вас поправим) Уменьшить конфигурацию виртуальной машины у нас так же просто, как и увеличить!
Единственное исключение — дисковая подсистема. Уменьшить размер диска, к сожалению, невозможно. В частности, поэтому мы реализовали возможность подключению доп. дисков. Если Вы подключаете доп. диск (подключать можно диски разных типов: SSD, SAS, SATA), то в последствии Вы можете его просто удалить. Если нужно на какое-то время увеличить размер дисковой подсистемы, мы всегда рекомендуем нашим клиентам использовать доп. диски.
+ Так же возможна миграция на лету между SAS и SSD дисками (в обе стороны).
Подобные формулировки Вы скорее всего найдете в договоре любого значимого провайдера. Дело в том, что хостеру защита от недобросовестного клиента нужна так же, как клиенту защите от недобросовестно хостера. При аренде виртуального сервера пользователь получает полные права администратора на нем, одному Богу известно, что он может там наворотить, где он может скомпрометировать учетные данные и т.д. Поэтому, ни один провайдер не будет разделять риски по потере данных или упущенной выгоде с клиентом, т.к. это затрагивает аспекты, на которые он просто не может влиять.
Как мы указывали выше, очень важно проводить мониторинг репутации провайдера, до того как начинать с ним работать. Репутация, репутация и еще раз репутация.
«после «своей инфраструктуры» у вас останется свое оборудование» — тут не стоит забывать, что серверное оборудование очень быстро устаревает. Через 5 лет у Вас на руках будет уже не классное серверное оборудование, а устаревшее, не отвечающее современным требованиям железо.
«вы по крайней мере перестаете зависеть от действий и проблем сторонней организации» — Да, но Вы начинаете зависеть от действий и компетенции собственных сотрудников, при том, что скорее всего это не Ваша профильная деятельность.
«защитите данные от посторонних лиц (ничего не стоит их потерять)» — Не сбрасывайте со счетов репутационные риски. Опасения ваши понятны, именно поэтому надо тщательно изучать репутацию хостера в сети. Если речь идет о сервисе однодневке, который предлагает «ошеломительно низкие цены» — то это безусловно зона риска. Если же речь идет о стабильной компании, которая дорожит своей репутацией, то вы можете не опасаться за свои данные. В интернете ничего не утаишь.
Спасибо за комментарий.
Но позвольте все же не согласиться с вами.
«С одной стороны приложение на виртуальном сервере работает медленнее» — есть большое количество систем виртуализации, какие-то написаны хорошо, а какие-то не очень. Соответственно сравнивать просто с системой виртуализации не совсем корректно. Ну и хотелось бы увидеть ссылку на авторитетный источник, который бы подтверждал вашу гипотезу.
«С другой стороны хостеру необходимо выделять ресурсы на более дорогую систему хранения данных, чтобы виртуальные машины клиентов быстрее очнулись при падении железа» - мы строим решение с системой хранения данных не потому что у нас виртуализация и не потому что мы хостер, а потому что мы ответственно подходим к вопросу сохранности клиентских данных. Коммерческие компании точно также используют СХД. И да, мы отделяем вычислительные ресурсы от дискового пространства, чтобы в случае сбоя на аппаратном хосте виртуальные машины Клиентов максимально быстро продолжили работу, также это позволяет нам проводить обслуживание аппаратных хостов, так что Клиенты этого не замечают.
Насчет стоимости: возможно взять 4 аппаратных хоста будет дешевле, но уж точно не более надёжно. Также в стоимость следует включить: систему резервирование на случай выхода из строя сервера, резервирование каналов связи и многое другое, что делает хостер и что потребуется делать Вам для того, чтобы добиться соответствующего качества услуги.
Такой подход имеет право на жизнь, при условии, что вы готовы заниматься поддержкой собственного решения с использованием виртуализации, а это весьма весомые трудозатраты, причем высококвалифицированных кадров.
Чтобы обеспечить стабильность и отказоустойчивость, нужно будет брать не один хост, а миниму два. Мы же гарантируем минимум N+1 хост в каждом кластере + у нас диски вынесены на дисковый массив NetApp, поэтому при любых проблемах виртуальные сервера гарантированно будут подняты на другом гости.
Если говорить про другие конкурентные преимущества, то мы сделали ставку на понятность интерфейсов и удобство работы с ними. Сейчас при переходе на 1cloud можно в разы сократить время, которое необходимо тратить на работу с виртуальной инфраструктурой. Если в случае работы с одним виртуальным сервером это может быть не особо критично, то при работе с более обширной виртуальной инфраструктурой выгода в затраченном времени растет в герметрической прогрессии.
И тут мы приходим к чему-то вроде «незаменимых нет»? Как раз такой подход и «губит» многих руководителей, которые относятся к разработчикам подобным образом
Тогда необходимость работы 24/7 отпадет, и переживать за возможные недоработки не придется :)
Кстати, в комментариях можно было бы обсудить предложения для следующих постов – какие туториалы могли бы быть интересны применительно к теме IaaS, например.
По поводу нового сайта: спасибо за предоставленный скриншот, обязательно устраним эту проблему в самое ближайшее время.
Как и указал ниже Nuur изменился параметр производительность.
Это связано с тем, что в Москве площадка построена исключительно на высокопроизводительном оборудовании. В отличии от площадки в СПБ в Москве есть только высокопроизводительный пул.
Когда Вы изменили параметр «Центр обработки данный» на Москву, конфигуратор переставил значение параметра «Производительность оборудования» на единственно возможное для Москвы значение «Высокая». При изменении параметра «Центр обработки данный» обратно на СПБ значение параметра «Производительность оборудования» на Базовая не изменилось, т.к. в СПБ доступны оба пула. В данный момент конфигуратор не видит разницы между тем, что значение параметра «Производительность оборудования» было изменено автоматически из-за смены локации или Вы его изменили самостоятельно.
Возможно это недоработка в юзабилити конфигуратора, но уж никак не «надувательство».
Но вам, большое спасибо за feedback. Мы обязательно рассмотрим этот момент и при необходимости и технической возможности внесем изменения в конфигуратор.
Хотя, справедливости ради нужно отметить, что такое поведение конфигуратора ни у кого прежде не вызывало затруднений, по крайней мере нам об этот не сообщали. Так что еще раз спасибо за инфу.
+ все-таки довольно сложно «не обратить на это внимание», т.к. кнопка заказа находится под итоговой ценой выделенной крупным шрифтом.
1) Предлагаем Вам провести тестирование с использованием нашей инфраструктуры. Ресурсы мы естественно предоставим бесплатно.
Если вам это интересно — напишите, пожалуйста, в личных сообщениях на хабре или нам на support@1cloud.ru, или в сообщения нашей страницы в Vk https://vk.com/1cloud, конфигурацию, на которой вы бы хотели провести тест. Так же можете просто зарегистрироваться в нашем сервисе и заказать нужную конфигурацию (напишите обращение в службу поддержки там же и сошлитесь на данную статью — мы выдадим тестовый период).
2) «При этом некоторые провайдеры (например, DO) лукавят. Они дают возможность увеличивать размер виртуалки, но уменьшить её размер невозможно. Если вам больше не нужна большая виртуалка, вы должны создать новую маленькую и перенести данные на неё. Действительная возможность изменять размер виртуальных машин в обе стороны есть только у AWS, Azure и Jelastic. Если у вас она тоже есть, поправьте меня, пожалуйста.»
С радостью Вас поправим) Уменьшить конфигурацию виртуальной машины у нас так же просто, как и увеличить!
Единственное исключение — дисковая подсистема. Уменьшить размер диска, к сожалению, невозможно. В частности, поэтому мы реализовали возможность подключению доп. дисков. Если Вы подключаете доп. диск (подключать можно диски разных типов: SSD, SAS, SATA), то в последствии Вы можете его просто удалить. Если нужно на какое-то время увеличить размер дисковой подсистемы, мы всегда рекомендуем нашим клиентам использовать доп. диски.
+ Так же возможна миграция на лету между SAS и SSD дисками (в обе стороны).
Как мы указывали выше, очень важно проводить мониторинг репутации провайдера, до того как начинать с ним работать. Репутация, репутация и еще раз репутация.
«вы по крайней мере перестаете зависеть от действий и проблем сторонней организации» — Да, но Вы начинаете зависеть от действий и компетенции собственных сотрудников, при том, что скорее всего это не Ваша профильная деятельность.
«защитите данные от посторонних лиц (ничего не стоит их потерять)» — Не сбрасывайте со счетов репутационные риски. Опасения ваши понятны, именно поэтому надо тщательно изучать репутацию хостера в сети. Если речь идет о сервисе однодневке, который предлагает «ошеломительно низкие цены» — то это безусловно зона риска. Если же речь идет о стабильной компании, которая дорожит своей репутацией, то вы можете не опасаться за свои данные. В интернете ничего не утаишь.
Но позвольте все же не согласиться с вами.
«С одной стороны приложение на виртуальном сервере работает медленнее» — есть большое количество систем виртуализации, какие-то написаны хорошо, а какие-то не очень. Соответственно сравнивать просто с системой виртуализации не совсем корректно. Ну и хотелось бы увидеть ссылку на авторитетный источник, который бы подтверждал вашу гипотезу.
«С другой стороны хостеру необходимо выделять ресурсы на более дорогую систему хранения данных, чтобы виртуальные машины клиентов быстрее очнулись при падении железа» - мы строим решение с системой хранения данных не потому что у нас виртуализация и не потому что мы хостер, а потому что мы ответственно подходим к вопросу сохранности клиентских данных. Коммерческие компании точно также используют СХД. И да, мы отделяем вычислительные ресурсы от дискового пространства, чтобы в случае сбоя на аппаратном хосте виртуальные машины Клиентов максимально быстро продолжили работу, также это позволяет нам проводить обслуживание аппаратных хостов, так что Клиенты этого не замечают.
Насчет стоимости: возможно взять 4 аппаратных хоста будет дешевле, но уж точно не более надёжно. Также в стоимость следует включить: систему резервирование на случай выхода из строя сервера, резервирование каналов связи и многое другое, что делает хостер и что потребуется делать Вам для того, чтобы добиться соответствующего качества услуги.
Чтобы обеспечить стабильность и отказоустойчивость, нужно будет брать не один хост, а миниму два. Мы же гарантируем минимум N+1 хост в каждом кластере + у нас диски вынесены на дисковый массив NetApp, поэтому при любых проблемах виртуальные сервера гарантированно будут подняты на другом гости.
Если говорить про другие конкурентные преимущества, то мы сделали ставку на понятность интерфейсов и удобство работы с ними. Сейчас при переходе на 1cloud можно в разы сократить время, которое необходимо тратить на работу с виртуальной инфраструктурой. Если в случае работы с одним виртуальным сервером это может быть не особо критично, то при работе с более обширной виртуальной инфраструктурой выгода в затраченном времени растет в герметрической прогрессии.