|
Я с 16 занимался различными игровыми серверами, сейчас уже третий год курирую игровой портал провайдера City OnLine (Москва), как хобби и дополнительная прибыль - не плохо. Нравилось. После получения бакалавра искал работу все лето (это же был кризис), сисадминского ничего так и не нашел, но подвернулась работа java-разработчика. Втянулся, понравилось еще больше. Особенно аутсорсинг, если компания с западными корнями - работать просто мечта. Офисы и процесс разработки - все по западному стилю, постоянные командировки за границу (я люблю путешествовать), и, как я сказал выше, уровень зарплат высок. Вилка джава джуниора 400-1000$ в Одессе, а это только первая ступень карьеры. Только не наступай на те же грабли, что и я - учи разговорный английский пока не поздно.
Потребность в админах растет, но в кодерах - еще больше. Пока еще очень мало софта, который хорошо параллелится не просто в разных потоках, а по MPI, клаудам, или вообще распределенно и независимо. (говоря проще, скалироваться сейчас мало что умеет, в контексте джавы - клауд-хостеров которые умеют более-менее нормально скалировать tomcat или jetty я знаю всего два)
Но еще больше сейчас растет мобильный рынок, iOS с андроидом это настоящий бум.
Со вторым - согласен, а вот насчет первого... Потребность то растет, но не в количестве, а в качестве.
Там где работал отдел из 3-5 человек, сейчас остается 1, и это не как не связано с кризисом, технологии позволяют.
Сегодняшние тренды: облака, виртуализация и т.д. сводят до минимума физическое участие сисадминов.
"Тренды" - это то, что сейчас активно развивается и понемногу идет в массы, можно сказать - недалекое будущее.
А сокращения - это сегодняшний день, когда, например, у фирмы есть несколько больших офисов и на каждом сидел админ, а сейчас кинули оптоволокно между ними и админов оставили только в центральном офисе и подняли з/п. Вот Вам и доплата за "профессионализм"![]()
Возможно и так, но это для контор, где ничего не менялось около 5-ти лет, база 1С висит на компе, который чуть мощнее пользовательских ПК, и гордо называется "СЕРВЕР",
или точно такой же на базе Линукса, который СВИД, он же Почтовый, он же ФТП, с несколькими сетевыми картами, и тоже именуемый СЕРВЕРом
Тогда, да.... это "модные слова".
А вот что касается молодых и перспективных компаний, тут уже другая ситуация, они предпочитают арендовать сервера в ДАТАЦЕНТРЕ где в качестве дополнительных плюшек будет: Ежедневное (а то и чаще) бекапирование, антивирусная защита, хостинг и т.д. и зачем им держать целый отдел ИТ для этого? достаточно одного штатного админа.
Еще, касательно Датацентров, если компания уж очень серьезно подходит к этому, то сервера арендуются в забугорных ДЦ типа Амазон
Так что....
Ранее сервер в соседней комнате, теперь в типа облаке какого то датацентра, с технической стороны разницы клиенту может быть практически никакой что если бы это просто стоял в виде железного отдельного сервака в том же дата центре, но теперь можно гордится что типа причасны к облачным вычислениям и все такое. Правильно было замечено, что ранее обо всем заботились сами, теперь еще и можно понадеятся на провайдера облака.
Так что требуемая квалификация могла изменится в несколько другую сторону, но чаще всего ее сильного роста не требуется.
Вон кстати соседний топик демонстрирует почему народ профессии админа предпочитает профессию программиста
PS аренда забугорного хостинга у нас больше связана с безопасностью бизнеса благодаря отечественным реалиям, чем с экономической точки зрения![]()
Собственно мы и пришли к тому о чем я говорил. Админы начинали с небольших контор, и вырастали до "упитанных и бородатых". Со студенческой скамьи никто не возьмет в ДАТАЦЕНТР, им подавай 5 лет стажа, а где его брать?
А насчет забугорных, это и имелось ввиду. Случаи с "Упс, у нас случился пожар. Сорри! =)" пугают больших дядей, тем более что все приличные компании имеют забугорные инвестиции.
Как и пугает тот момент что прийдут и скажут а где у вас тут наклеечки на компьютерах и т.п. Кстати это еще часто отдельный момент который ложиться на плечи админов и бухов.
Вспоминается прочитанная где то инете история, про сервера со связью через wifi в машине которая стоит в подземном паркинге и готова в любой момент покинуть опасную территорию
До тех пор пока существуют криворукие программеры, работа у админов будет.
Ну попробую на веб программировании.
1) Как пишут в умных книжках закрывать соединение с базой совсем необязательно. Многие так и делаю. Только вот когда запросов стает много коннекты по таймауту не успевают вылетать и тупо выжыраются все свободные хендлы. После этого на сайте созерцаем "To many connection to database". База в ауте
2) То что можно сделать средствами БД делается на скриптах. Разница в производительности иногда уж очень большая.
3) Корявые джойны. Когда то развлекался с запросами и разница в скорострельности между 2 запросами возвращающими одни и теже данные была порядка 150 раз
4) Все что движется и недвижется храним в базе. Неоднократно созерцал хранение в базе картинок.
5) Нет оптимизируется изображения под максимальный размер для отображения. Пользователь залил размером 2400x1800 хз сколько метровую фотку а на сайте она отображается в размере 240x180 просто зажата хтмл тегами
и т.д и т.п
Это конечно примеры плохого программирования, но как тут помогает админ? Я конечно поминаю что есть случаю когда промах программиста может еще кое как подкостылить админ, но это не преобладает в профессии админа.
ЗЫ: Кстати а зачем соединения к базе закрывают, а не используют их для следующих запросов?
Так по вашему мнению нужно идти на программиста?
Инфа с php.net немного устарела, но общий смысл проглядывается. Да все равно какие вы коннекты используете, если вы не умеете с ними обращатся, то все до лампочки.
Here's a recap of important reasons NOT to use persistent connections:
* When you lock a table, normally it is unlocked when the connection closes, but since persistent connections do not close, any tables you accidentally leave locked will remain locked, and the only way to unlock them is to wait for the connection to timeout or kill the process. The same locking problem occurs with transactions. (See comments below on 23-Apr-2002 & 12-Jul-2003)
* Normally temporary tables are dropped when the connection closes, but since persistent connections do not close, temporary tables aren't so temporary. If you do not explicitly drop temporary tables when you are done, that table will already exist for a new client reusing the same connection. The same problem occurs with setting session variables. (See comments below on 19-Nov-2004 & 07-Aug-2006)
* If PHP and MySQL are on the same server or local network, the connection time may be negligible, in which case there is no advantage to persistent connections.
* Apache does not work well with persistent connections. When it receives a request from a new client, instead of using one of the available children which already has a persistent connection open, it tends to spawn a new child, which must then open a new database connection. This causes excess processes which are just sleeping, wasting resources, and causing errors when you reach your maximum connections, plus it defeats any benefit of persistent connections.
1) Изменение размеров буферов и таймаутов в базе
+ Принудительное закрытие хендлов в конце выполнения скрипта. Делается по разному. Самый простой способ, аппендить в php.ini дополнительный скрипт.
2) То что можно сделать средствами БД делается на скриптах. Разница в производительности иногда уж очень большая.
Прикрутить оптимизатор.
3) Корявые джойны. Когда то развлекался с запросами и разница в скорострельности между 2 запросами возвращающими одни и теже данные была порядка 150 раз
Увеличение кэша БД. Чтобы идиотские выборки хранились Либо наоборот уменьшить, чтобы был отловлен программер.
4) Все что движется и недвижется храним в базе. Неоднократно созерцал хранение в базе картинок.
Здесь можно создание кэшей картинок на лету организовывать. Если картинки по урлу нет, то запустить обработку скрипта, если есть то отдать ее
5) Нет оптимизируется изображения под максимальный размер для отображения. Пользователь залил размером 2400x1800 хз сколько метровую фотку а на сайте она отображается в размере 240x180 просто зажата хтмл тегами
Приблизительно тоже самое что 4 пункт
Социальные закладки